On Fri, Jul 25, 2014 at 12:40:04AM +0300, Siarhei Siamashka wrote: > 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.
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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
