From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 8 Jan 2019 12:49:16 +0100 Subject: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata In-Reply-To: References: <20190107211423.10151-1-simon.k.r.goldschmidt@gmail.com> <1f8fdec8-68d0-ad64-350d-5d290294a0cf@denx.de> Message-ID: 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 7:56 AM, Simon Goldschmidt wrote: > On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut wrote: >> >> On 1/7/19 10:14 PM, Simon Goldschmidt wrote: >>> This is an initial attempt to support OF_PLATDATA for socfpga gen5. >>> >>> There are two motivations for this: >>> a) reduce code size to eventually support secure boot (where SPL has to >>> authenticate the next stage by loading/checking U-Boot from a FIT >>> image) >>> b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM >>> (on warm-restart), all bytes to check need to be in one piece. With >>> OF_SEPARATE, this is not the case (.bss is between .rodata and the >>> DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to >>> be a good solution. >> >> I'd much prefer parsing the DT (and thus, decoupling the SW from HW) >> than having some ad-hoc plat data again if we can avoid that. > > So you're against the whole OF_PLATDATA thing or how should I understand > that? If we can avoid it, I'd prefer to do so. > It's not really ad-hoc, it's the DT converted to C structs. It's just in another > format, but it's still (sort of) decoupled SW from HW. > > As written above, I have two goals I want to achieve with this. Right now, I > cannot enable verified boot in SPL because the available OCRAM cannot > hold all the code. And it seemed to me OF_PLATDATA could help me there. Well this might be a long shot, but I discussed this lack of OCRAM during 35C3 and there was a suggestion to lock L2 cache lines above ROM (so there's some backing store) and use that as extra SRAM. Would that help you ? -- Best regards, Marek Vasut