From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Gortmaker Date: Sat, 17 Oct 2015 19:11:26 -0400 Subject: [U-Boot] [PATCH 0/6] sbc8641d: misc fixes and generic board enablement In-Reply-To: <20151017225026.GT26878@windriver.com> References: <1445114431-9524-1-git-send-email-paul.gortmaker@windriver.com> <20151017215021.GV23893@bill-the-cat> <20151017225026.GT26878@windriver.com> Message-ID: <20151017231126.GU26878@windriver.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de [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? Paul. -- > > P. > -- > > > > > -- > > Tom > >