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 <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?). > > 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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot