On Thu, 24 Jul 2014 11:00:31 -0400
Tom Rini <tr...@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 <w...@csie.org> wrote:
> >
> > > On Thu, Jul 24, 2014 at 11:12 AM, Siarhei Siamashka
> > > <siarhei.siamas...@gmail.com> wrote:
> > > > On Thu, 5 Jun 2014 19:00:14 +0100
> > > > Ian Campbell <i...@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 <i...@hellion.org.uk>
> > > >> Acked-by: Hans de Goede <hdego...@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.
> 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 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).
--
Best regards,
Siarhei Siamashka
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
