From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Mon, 22 Apr 2019 21:50:04 +0200 Subject: [U-Boot] [PATCH v4 0/4] configs: rk3288: Tinker Board SPL file must fit into 32 KiB In-Reply-To: <20190422192916.GQ4664@bill-the-cat> References: <20190402171907.17929-1-xypron.glpk@gmx.de> <20190422143641.GZ4664@bill-the-cat> <20190422192916.GQ4664@bill-the-cat> Message-ID: <17eccb26-370a-deff-c74d-bdd9046df3d8@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 22.04.19 21:29, Tom Rini wrote: > On Mon, Apr 22, 2019 at 08:40:52PM +0200, Simon Goldschmidt wrote: >> Am 22.04.2019 um 16:36 schrieb Tom Rini: >>> On Thu, Apr 18, 2019 at 10:12:36PM +0200, Simon Goldschmidt wrote: >>>> Heinrich, >>>> >>>> On 02.04.19 19:19, Heinrich Schuchardt wrote: >>>>> The SPL image for the Tinker Board has to fit into 32 KiB. This includes >>>>> up to 2 KiB for the file header. >>>>> >>>>> A new configuration variable CONFIG_SPL_SIZE_LIMIT is introduced to define >>>>> the board specific limit. >>>>> >>>>> A common Makefile function is used for this test and the test against >>>>> CONFIG_BOARD_SIZE_LIMIT. >>>>> >>>>> Move the board size check from arch/arm/mach-imx/Makefile to Makefile. >>>> >>>> Has anything from this series been applied? I now have a working patch that >>>> applies on top of this and adds a full SPL SRAM size check (including HEAP, >>>> GD and stack; via a host tool) which works for socfpga (as an example of a >>>> platform where SPL binary is loaded to limited SRAM). >>>> >>>> Actually, my patch would replace your patch 3/4 but build on 1/4 (2/4 and >>>> 4/4 are arch-specific). >>>> >>>> How should we proceed here? I could send a series including your 1/4, or I >>>> could send a series completely building on this series, at the downside of >>>> more or less reverting your 2/4. >>> >>> What I would like to see is i.MX (and rockchip) converted to use your >>> new test as well (also, yay! Thanks for following up on that!) and we >>> drop the existing check here. >> >> Ok, so while I cannot really help on i.MX and rockchip, why don't you accept >> this series from Heinrich and I'll send my patch as followup? Then we can >> discuss this with i.MX and rockchip maintainers. > > Can you post your series now, and we can move from there? Thanks! Did that: https://patchwork.ozlabs.org/patch/1088865/ [Depends on this series from Heinrich] Regards, Simon