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

[Tom Rini]

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?
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.  I expect Simon to possibly chime in here as he's done some work
in the past on this concept, for all CONFIG options (but I'm not sold on
the idea for use everywhere, just yet anyhow).

-- 
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/20140724/1ee99094/attachment.pgp>