[U-Boot] [PATCH 3/6] sunxi: add Cubieboard2 support

[Tom Rini]

On Fri, Jul 25, 2014 at 12:40:04AM +0300, Siarhei Siamashka wrote:
> On Thu, 24 Jul 2014 11:00:31 -0400
> Tom Rini <trini at ti.com> wrote:
> 
> > On Thu, Jul 24, 2014 at 03:47:53PM +0300, Siarhei Siamashka wrote:
> > > On Thu, 24 Jul 2014 11:18:15 +0800
> > > Chen-Yu Tsai <wens at csie.org> wrote:
> > > 
> > > > On Thu, Jul 24, 2014 at 11:12 AM, Siarhei Siamashka
> > > > <siarhei.siamashka at gmail.com> wrote:
> > > > > On Thu,  5 Jun 2014 19:00:14 +0100
> > > > > Ian Campbell <ijc at hellion.org.uk> wrote:
> > > > >
> > > > >> This is a sun7i (A20) based followup to the sun4i (A10)
> > > > >> Cubieboard. It has GMAC using MII mode.
> > > > >>
> > > > >> Signed-off-by: Ian Campbell <ijc at hellion.org.uk>
> > > > >> Acked-by: Hans de Goede <hdegoede at redhat.com>
> > > > >
> > > > > This board is using exactly the same PCB as the Cubieboard1. And only
> > > > > the SoC is different (Allwinner A20 instead of the pin-compatible
> > > > > Allwinner A10).
> > > > >
> > > > > Before piling up more board configurations, we might want to consider
> > > > > supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary
> > > > > (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg).
> > > > > The Allwinner SoCs have support for runtime identification of the SoC
> > > > > type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at
> > > > > the address 0x01C00024 as explained in the Allwinner A20 user manual.
> > > > > This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I
> > > > > ifdefs in the u-boot code with a runtime SoC type checks, but there
> > > > > are not too many places affected (mostly just the DRAM code).
> > > > 
> > > > A20 will need PSCI for SMP and virtualization support.
> > > > (I know the related code isn't in there yet.)
> > > > Won't this be slightly hard to do if you mix them together?
> > > 
> > > Thanks, that's a good point. Do you expect any special challenges other
> > > than just having to handle runtime SoC detection in more places and
> > > deal with larger final binaries on the hardware, which does not need
> > > PSCI itself?
> > 
> > We have similar issues to deal with on most TI SoCs as well.  We want to
> > share code as much as possible to avoid duplication, etc.  As for
> > run-time sharing, that's where it gets trickier.  You're going to have
> > some sort of size constraint on your binary so just how close are you to
> > hitting it today on the smaller of the parts that you would run this on?
> 
> As far as I know, the most SRAM space constrained case on Allwinner
> hardware used to be the FEL boot mode, where we only had roughly ~15K
> for the SPL (code, data, stack). This can be improved though:
> 
>     http://lists.denx.de/pipermail/u-boot/2014-July/183985.html
> 
> But I need to verify the SRAM size constraints again and come up with
> the detailed numbers. And also have a closer look at how this all
> interacts with the PSCI support.

Yeah, it's important to get the worst-case numbers just right.  OMAP4 is
ours and that's pretty tight :(

> > In some cases, for the first part of the problem, we may want to do "if
> > (is_sun4i()) { ... }" code that boils down to a compile-time check
> > anyhow.
> 
> Right, if the 'is_sun4i()' is a macro (should it be lower or upper
> case?), which expands to a compile time constant 0 or 1 in some
> configurations instead of the runtime checks, then the compiler is
> normally able to remove the unreachable parts of code and save space.
> This is a more flexible approach than using ifdefs.

I use board_is_foo() in the TI SoC cases where we have one config that
supports many boards of the same SoC family (ie am335x_evm supports
beaglebone black/white, GP EVM, EVM SK and IDK EVM, and various revs of
the boards too as needed).  So board_is_sun4i(), etc sounds fine with
me.  The only tricky part of compile-time consolidation is making sure
you don't get bit by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140725/f3d1323e/attachment.pgp>