On 11/09/2015 08:48 AM, Thierry Reding wrote:
On Mon, Nov 09, 2015 at 08:19:48AM -0700, Stephen Warren wrote:
On 11/09/2015 07:36 AM, Thierry Reding wrote:
On Wed, Oct 28, 2015 at 11:59:04AM -0600, Stephen Warren wrote:
On 10/18/2015 10:57 PM, Alexandre Courbot wrote:
T210's GPU secure firmware loading requires a write-protected region to be set up.
This patch reserves the upper 256KB of RAM as the WPR region and locks it so the kernel can initiate secure firmware loading.
On T210, it's the responsibility of nvtboot (which runs before U-Boot) to set up any and all carve-outs. This code should not be necessary, and indeed I expect the registers it touches can't actually be programmed from U-Boot, which runs in non-secure mode after WPR is already locked.
Can we document this assumption somewhere? It's entirely possible that someone might want to run U-Boot without nvtboot
That's not currently a supported use-case.
Isn't the whole point of open-source for people to be able to do all the things that aren't supported?
Sure, but the default case that we support should "just work", and be represented by the code we ship, and be supported by us. Any non-default case is going to require some research or additional coding/fixing/... effort, and we haven't necessarily published the information require to make those cases work.
, in which case nvtboot would still need to be responsible for setting this up.
I assume s/nvtboot/whatever other bootloader is in use/?
Right, I was going to write U-Boot here, but that's obviously only true if U-Boot is still running in secure mode. Otherwise, yes, it'd be what- ever is the other bootloader being used.
Or if it isn't we could still point at some location where the interactions between a first stage bootloader and U-Boot are documented.
Do we have a document of this kind already?
The L4T U-Boot source code:-)
There's a bunch of things that even the L4T U-Boot doesn't document. The fact that it doesn't initialize the SMMU or WPR doesn't indicate that it is something that a first stage bootloader needs to do.
I meant this more along the lines of "if there's no code to do something in L4T U-Boot, upstream U-Boot wouldn't need that code either". That should be true at least w.r.t. nvtboot integration; certainly there are features that only exist in upstream U-Boot and haven't been back-ported downstream. I wasn't really implying that there's actual documentation (comments) in the L4T U-Boot source code.