[PATCH] ARM64: juno: add NOR flash to device tree
ard.biesheuvel at linaro.org
Mon Oct 19 07:40:41 PDT 2015
On 19 October 2015 at 13:39, Mark Rutland <mark.rutland at arm.com> wrote:
> 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
> 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.
I sent some patches around about a year ago that registers UEFI
runtime MMIO regions with /proc/iomem, which should prevent drivers
from attaching to the same physical memory regions. With that in
place, describing it in the DT would not be a problem, and on devices
with multiple NOR flashes of which only one is used at runtime by
UEFI, it would allow Linux to still access the other one.
More information about the linux-arm-kernel