[U-Boot] [PATCH 0/6] sbc8641d: misc fixes and generic board enablement

[Tom Rini]

On Sat, Oct 17, 2015 at 07:11:26PM -0400, Paul Gortmaker wrote:
> [Re: [PATCH 0/6] sbc8641d: misc fixes and generic board enablement] On 17/10/2015 (Sat 18:50) Paul Gortmaker wrote:
> 
> > [Re: [PATCH 0/6] sbc8641d: misc fixes and generic board enablement] On 17/10/2015 (Sat 17:50) Tom Rini wrote:
> > 
> > > On Sat, Oct 17, 2015 at 04:40:25PM -0400, Paul Gortmaker wrote:
> > > 
> > > > The sbc8641d is not really a state of the art board anymore, but it
> > > > does have the distinctive feature of being one of the relatively few
> > > > SMP powerpc boards around.  Combined with its small form factor, it
> > > > remains a useful testing platform.  So here we enable the generic
> > > > board support so that it can remain in tree.
> > > > 
> > > > It turns out that in bringing the board forward, we've run into the
> > > > size limit for the image, due to inevitable expansion, which led
> > > > to some odd testing behaviour, depending on .config settings etc.
> > > > Here we increase the image space from two 128k sectors to three,
> > > > so we should be good for as long as the board remains relevant now.
> > > 
> > > Thanks for finding this.  I am going to grab this for the release and I
> > > might re-word a commit or two.  I have one ask tho, can you look at
> > > using CONFIG_BOARD_SIZE_LIMIT, perhaps in a generic way so that we catch
> > > more "oops, the board grew too big, run-time now will fail!" issues?
> > 
> > Yeah, I'll have a look -- I was kind of surprised that it didn't scream at
> > me when this happened during the build, since I'd think we have all the
> > information at our fingertips to do a build bug on or similar, and I
> > can't be the 1st one bitten by this.
> 
> So, it seems we already have this in a "generic" way via
> BOARD_SIZE_LIMIT but hardly anyone sets that for their board.
> 
> u-boot$git grep -l CONFIG_BOARD_SIZE_LIMIT include/
> include/configs/bf548-ezkit.h
> include/configs/bf609-ezkit.h
> include/configs/bfin_adi_common.h
> include/configs/cm-bf537e.h
> include/configs/cm-bf537u.h
> include/configs/colibri_pxa270.h
> include/configs/colibri_vf.h
> include/configs/pcm052.h
> include/configs/tcm-bf537.h
> include/configs/vf610twr.h
> u-boot$
> 
> Can we just assign CONFIG_SYS_MONITOR_LEN to CONFIG_BOARD_SIZE_LIMIT if
> the latter isn't explicitly set?  Or will that not be valid in some
> cases?

Right, that's what I was hoping you could poke at a bit and see about,
at least when CONFIG_SYS_MONITOR_LEN is set (in a post v2015.10 patch
too, that is).

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