| Message ID | CACPK8XerZV+3RbxofpghWioYC68kK531aQQ_Jc8ZYLrjjCUqjQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote: > Hi Arnd and Olof, > Aspeed devicetree updates for 4.14 > > - fix to expose the full flash windows on ast2400. > Pulled into next/dt, thanks! Can you explain the CONFIG_VMSPLIT_2G requirement mentioned in the changelog here? Will it stop working with a normal multiplatform configuration that uses VMSPLIT_3G, or just have no effect? Arnd
On 08/24/2017 01:13 PM, Arnd Bergmann wrote: > On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote: >> Hi Arnd and Olof, >> Aspeed devicetree updates for 4.14 >> >> - fix to expose the full flash windows on ast2400. >> > > Pulled into next/dt, thanks! Can you explain the CONFIG_VMSPLIT_2G > requirement mentioned in the changelog here? Will it stop working with > a normal multiplatform configuration that uses VMSPLIT_3G, or just > have no effect? The kernel will still boot but, without VMSPLIT_2G, the SPI flash controller driver will fail to map the memory windows of the flash devices. And the system will surely lack a root filesystem. C.
On Thu, Aug 24, 2017 at 5:06 PM, Cédric Le Goater <clg@kaod.org> wrote: > On 08/24/2017 01:13 PM, Arnd Bergmann wrote: >> On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote: >>> Hi Arnd and Olof, >>> Aspeed devicetree updates for 4.14 >>> >>> - fix to expose the full flash windows on ast2400. >>> >> >> Pulled into next/dt, thanks! Can you explain the CONFIG_VMSPLIT_2G >> requirement mentioned in the changelog here? Will it stop working with >> a normal multiplatform configuration that uses VMSPLIT_3G, or just >> have no effect? > > The kernel will still boot but, without VMSPLIT_2G, the SPI flash > controller driver will fail to map the memory windows of the flash > devices. And the system will surely lack a root filesystem. Hmm, why does the flash controller even map the entire area? IIRC, NOR flash controllers normally have a 'ranges' property that gets set up to list the available memory ranges, and the chips attached to them have the 'reg' property that matches the actual size. Arnd
On 08/24/2017 11:24 PM, Arnd Bergmann wrote: > On Thu, Aug 24, 2017 at 5:06 PM, Cédric Le Goater <clg@kaod.org> wrote: >> On 08/24/2017 01:13 PM, Arnd Bergmann wrote: >>> On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote: >>>> Hi Arnd and Olof, >>>> Aspeed devicetree updates for 4.14 >>>> >>>> - fix to expose the full flash windows on ast2400. >>>> >>> >>> Pulled into next/dt, thanks! Can you explain the CONFIG_VMSPLIT_2G >>> requirement mentioned in the changelog here? Will it stop working with >>> a normal multiplatform configuration that uses VMSPLIT_3G, or just >>> have no effect? >> >> The kernel will still boot but, without VMSPLIT_2G, the SPI flash >> controller driver will fail to map the memory windows of the flash >> devices. And the system will surely lack a root filesystem. > > Hmm, why does the flash controller even map the entire area? > > IIRC, NOR flash controllers normally have a 'ranges' property that > gets set up to list the available memory ranges, and the chips > attached to them have the 'reg' property that matches the actual > size. Yes, that is the common scenario. The SMC controller of the Aspeed SoC uses a global memory window (defined by HW for each controller) on which the chips contents can be memory mapped. This is up to the software using 'segment' registers to organize how the mapping of each chip is done. There are some HW constraints on alignments, overlaps and on the values of the start and end addresses of each segment. For instance, the start address of the first segment should be equal to the start address of the global window and the end address of the last segment should be equal to the end address of the global window. Also, most of the backplanes (all IBMs) have sockets holding the flash devices, so you don't necessarily know which model and how many chips are available. Some boards have a couple of flash devices which can cover the full window, some have large ones, like the witherspoon which uses a 128MB chip for the host firmware. So, the driver does its best to discover the flash layout at probe time, maps the full area and configures the segment registers accordingly. The start address of each segment is then used to send SPI commands when the controller is in I/O mode. When the controller is set to use memory mode, the full memory range can be used to access the flash contents directly. I agree that we could probably probe the chips, configure the segment registers and then only map the required area. Some configurations would still need the whole window but there might be room for some improvements. C.
Hi Arnd and Olof, Here's an Aspeed devicetree change for 4.14. As with the defconfig pull, this change has been kicking around for a while now so it is well tested. The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git tags/aspeed-4.14-devicetree for you to fetch changes up to bcbd328d3fe765f333642b7cfe384d59dffc2db2: ARM: dts: aspeed-g4: fix AHB window size of the SMC controllers (2017-08-23 16:06:02 +0930) ---------------------------------------------------------------- Aspeed devicetree updates for 4.14 - fix to expose the full flash windows on ast2400. ---------------------------------------------------------------- Cédric Le Goater (1): ARM: dts: aspeed-g4: fix AHB window size of the SMC controllers arch/arm/boot/dts/aspeed-g4.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)