On Thu, May 30, 2019 at 12:50:12PM +0200, Linus Walleij wrote:
> On Thu, May 30, 2019 at 11:11 AM Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
>
> > Accessing the NOR flash memory from the kernel will disrupt CPU sleep/
> > idles states and CPU hotplugging. We need to disable this DT node by
> > default. Setups that want to access the flash can modify this entry to
> > enable the flash again but also ensuring to disable CPU idle states and
> > CPU hotplug.
> >
> > The platform firmware assumes the flash is always in read mode while
> > Linux kernel driver leaves NOR flash in "read id" mode after
> > initialization. If it gets used actively, it can be in some other state.
> >
> > So far we had not seen this issue as the NOR flash drivers in kernel
> > were not enabled by default. However it was enable in multi_v7 config by
> > Commit 5f068190cc10 ("ARM: multi_v7_defconfig: Enable support for CFI NOR FLASH")
> >
> > So, let's mark the NOR flash disabled so that the platform can boot
> > again. This based on:
> > Commit 980bbff018f6 ("ARM64: juno: disable NOR flash node by default")
> >
> > Cc: Liviu Dudau <liviu.dudau@xxxxxxx>
> > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
> > Signed-off-by: Sudeep Holla <sudeep.holla@xxxxxxx>
>
> Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
>
Thanks.
> It's a bit sad that this cannot be easily fixed (I don't know if it can even
> be fixed with firmware updates?), it's kind of useful to be able to
> update the flash from within Linux, as that mimics what pretty much
> every IoT device (such as routers) is doing and would be nince for
> an OpenWrt port.
>
IMO, it issue with partitioning of the system. Basically these traditional
NOR flash don't support partitions at hardware level so that one accessed
by firmware/secure side is protected from another accessed from non-secure.
I like the eMMC boot partitions in that ways as these are hardware
partitions and the device state is separate for these.
Also, ideally firmware/secure side should just restrict themselves to
Secure ROM, but as a record we consistently ensure firmware on SROM is
busted and use non-secure ROM/NOR Flash as bypass :) which then makes
it tricky to deal with such scenarios in Linux. Hope we fill have some
system with everything working *one day* :D
--
Regards,
Sudeep
