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 <ma...@denx.de> wrote: > >>>> > >>>> On 1/8/19 1:09 PM, Simon Goldschmidt wrote: > >>>>> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut <ma...@denx.de> wrote: > >>>>>> > >>>>>> On 1/8/19 7:24 AM, Simon Goldschmidt wrote: > >>>>>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut <ma...@denx.de> 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?). -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
