[PATCH] ARM64: juno: add NOR flash to device tree

[Mark Rutland]

On Mon, Oct 19, 2015 at 01:19:14PM +0200, Linus Walleij wrote:
> On Mon, Oct 19, 2015 at 12:29 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> 
> > Also, for non U-Boot systems I was under the impression that the flash
> > was effectively owned by EFI (for variable storage),
> 
> If it is "owned" by something it is owned by the boot monitor, neither
> by U-Boot or (U)EFI. The boot monitor can flash "images" into
> the flash using USB or ethernet/TFTP and it is not part of any
> boot loader, but an autonomous flash image on the board.
> (Actually it can replace itself.)
> 
> EFI or U-Boot is one such "image", as is the kernel and the
> other patch series I've sent (AFSv2 support) makes these
> "images" visible to the kernel as individual MTD partitions.

I understand this.

> This flash image format has nothing to do with UEFI or any other
> boot loader, it has been around since the RealView platforms,
> and has basically not changed since. (Well the forst pointer in
> the image information structure was changed from u32 to u64).
> 
> My impression is that the boot monitor code is just a continous
> evolution from reference design to reference design inside ARM.
> It cares very little about what boot loader happens to be the
> fashion of the day, it is also used for flashing images of Windows
> mobile or QNX or whatever people want to run as well.

I'm on about _runtime_ firmware (UEFI and/or Arm Trusted Firmware), not
the first stage firmware that's out of the way by the time the OS is
active.

As I mentioned, I was under the impression that at least a portion of
the flash was used by UEFI for variable storage, and that UEFI could
therefore access the flash at runtime (due to runtime services calls).

Accessing the flash at the same time as another agent (UEFI or the
Trusted Firmare) does not seem like a good idea, and is potentially
unsafe (see Sudeep's example w.r.t. cpuidle).

> The "images" are very simplistic things designed to support
> execute-in-place. New images can be added/removed by any
> compliant software, be it EFI, U-Boot or the kernel. But the
> format of these images is part of the hardware or rather the boot
> monitor, nothing else.

This is technically true. However, my argument is not that this doesn't
describe the hardware, but rather that this describes a piece of
hardware which it is not safe to use unless it is known that any runtime
firmware is not concurrently accessing it.

Given that there is no mechanism to mediate access to the flash,
allowing Linux to access it does not seem safe.

Thanks,
Mark.