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...
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
