From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 8 Jan 2019 10:11:33 -0500 Subject: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select In-Reply-To: <73d1b4be-2496-5563-dbd6-b82475996a52@gmail.com> References: <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> <73d1b4be-2496-5563-dbd6-b82475996a52@gmail.com> Message-ID: <20190108151133.GU5463@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Jan 08, 2019 at 04:04:12PM +0100, Simon Goldschmidt wrote: > Am 08.01.2019 um 15:58 schrieb Tom Rini: > >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?). > > I'm not saying this was directed to me (I'm sure it wasn't). Just to clarify > my point: I'm really just trying to get the most basic SPL to work that > loads U-Boot as FIT from spi-flash and verifies it. It might well be that > it's this verified FIT offset that could be reduced... Oh no, I'm just listing the worst case of am335x, which is my fault, and goes well over the generous 100k+ that we have available there. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: