From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 8 Jan 2019 16:05:16 +0100 Subject: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select In-Reply-To: <20190108145814.GS5463@bill-the-cat> References: <20190107211423.10151-2-simon.k.r.goldschmidt@gmail.com> <033b301a-612d-3b80-7ecc-04530851c1ec@denx.de> <1ea65b3c-0332-ff07-1f51-7de306d9f2b5@denx.de> <339ceb3d-4a7c-bd23-0ce4-eb9e24d278df@denx.de> <20190108144842.GR5463@bill-the-cat> <7d6ad8e5-ef68-b65e-e2d8-45082da8017a@denx.de> <20190108145814.GS5463@bill-the-cat> Message-ID: <87a81a6d-7883-e4eb-cc5b-d292b2b810eb@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 1/8/19 3:58 PM, Tom Rini wrote: > On Tue, Jan 08, 2019 at 03:50:48PM +0100, Marek Vasut wrote: >> On 1/8/19 3:48 PM, Tom Rini wrote: >>> On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote: >>>> On 1/8/19 1:46 PM, Simon Goldschmidt wrote: >>>>> On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut wrote: >>>>>> >>>>>> On 1/8/19 1:09 PM, Simon Goldschmidt wrote: >>>>>>> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut wrote: >>>>>>>> >>>>>>>> On 1/8/19 7:24 AM, Simon Goldschmidt wrote: >>>>>>>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut wrote: >>>>>>>>>> >>>>>>>>>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote: >>>>>>>>>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and >>>>>>>>>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled >>>>>>>>>>> via defconfig. >>>>>>>>>>> >>>>>>>>>>> This also seems to be required to use OF_PLATDATA, as the reset drivers >>>>>>>>>>> don't seem to work with it. >>>>>>>>>> >>>>>>>>>> How do you un-reset IP blocks if you disable the reset controller ? >>>>>>>>> >>>>>>>>> Here again, socfpga seems to be another bad example. Taking >>>>>>>>> peripherals out of reset >>>>>>>>> is cluttered throughout the mach-socfpga code at least in SPL. By now >>>>>>>>> I know socfpga is >>>>>>>>> lacking support for clock and reset management via devicetree. And >>>>>>>>> this is bad, I know, >>>>>>>>> but can we keep this a seperate issue from OF_PLATDATA? >>>>>>>>> >>>>>>>>> That being said, drivers/reset/reset-uclass.c fails to compile with >>>>>>>>> OF_PLATDATA, so I >>>>>>>>> guess this has not been used with OF_PLATDATA before. And given that I >>>>>>>>> don't seem >>>>>>>>> to need it for socfpga either, I don't think this would be the right >>>>>>>>> series to fix that. >>>>>>>> >>>>>>>> Don't you need it to unreset at least the DWMMC or CQSPI ? >>>>>>> >>>>>>> Reading the code, it seems like that's taken care of through another hack in >>>>>>> spl_boot_device() ;-) >>>>>> >>>>>> Sigh. >>>>>> >>>>>>>> Anyway, I'd much prefer to start cleaning up the horrorshow that >>>>>>>> arch/arm/mach-socfpga is in terms of clock and reset, at least like A10. >>>>>>>> Would that be possible ? >>>>>>> >>>>>>> I would be best, yes. I don't know when I will find the time to do that, though. >>>>>>> I don't know how much effort that would be, either. Is there maybe a patch >>>>>>> where A10 got converted from "as bad as gen5" to its current state? That >>>>>>> would help me to see if I can do it... >>>>>> >>>>>> A10 got switched to reset framework recently (in last 6 months or so), >>>>>> the reset driver is the same for Gen5 and A10 too, so it should be easy >>>>>> to recycle. >>>>> >>>>> Hmm, ok, let me check that... it would indeed be nice to port this to gen5. >>>>> >>>>> Since you seem kidn of opposed to OF_PLATDATA, does it make any sense >>>>> to continue on this? I mean, I thought I heard people here saying "use >>>>> OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not too >>>>> keen on using it, either, but it does seem to give me some code space back... >>>> >>>> OF_PLATDATA is for platforms with really small SRAM, some 30k or below. >>>> This platform has a massive 60k of SRAM for SPL, so if we're running out >>>> of space, we're doing something wrong. >>> >>> It's not for "30k or below" but "needs more space to enable all desired >>> features inside of SPL". >> >> Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so >> bloated that even platform with so much space has issues, how can we >> even cater for the rest of platforms with much more limited SPL ? And if >> that is the case, we have a much bigger problem ... > > It depends, greatly, on what features you want within a single binary. > I'm not saying SoCFPGA can't fit what it wants, including verified boot, > inside of 60k. But what I am saying is we don't have a hard-and-fast > limit on when you must not use OF_PLATDATA since it's always been easy > to make SPL too big, once you start including all of the possible > kitchen sink options (lets do falcon mode, and boot count and usb gadget > and usb host and regular ethernet and mmc and nand and oh crap, where > did all of my space go?). Sure, but then maybe you do need to remove some of that stuff and configure the SPL for that one single need you have. -- Best regards, Marek Vasut