Dear colleagues and NXP technical support,
I can't figure out the length of page read access for NOR flash by LS1043A's IFC (IFC_CSORn_NOR[PGRD_EN] = 1). How can a software affect the burst size? Or is it fixed?
I have read the Introduction to Integrated Flash Controller and a Comparison with Enhanced Local Bus Controller and ...
I'm asking because all parallel NOR flashes we've found have 32B page size, even for example MT28EW used in LS1043A-RDB, so if 64B was fixed value, it would cause IFC in LS1043A unusable for page access with most flashes and this really seems like wrong reasoning from our side.
In LS1043A's reference manual there is explanation based on system bus' multi-beat transactions, but to be honest, I do not understand ARM's internal architecture enough to understand that. Please, can anyone simplify this explanation?
Hello Cyril Strejc,
Burst size in NOR is governed by system bus size and length.
In Linux Kernel configuration file, the following options are define.
CONFIG_MTD_MAP_BANK_WIDTH_1 Support 8-bit buswidth
CONFIG_MTD_MAP_BANK_WIDTH_2 Support 16-bit buswidth
CONFIG_MTD_MAP_BANK_WIDTH_4 Support 32-bit buswidth
Please refer to the following definition in ./include/linux/mtd/map.h.
# ifdef map_bankwidth
# undef map_bankwidth
# define map_bankwidth(map) ((map)->bankwidth)
# define map_bankwidth(map) 4
# define map_bankwidth_is_large(map) (0)
# define map_words(map) (1)
static inline map_word inline_map_read(struct map_info *map, unsigned long ofs)
r.x = __raw_readb(map->virt + ofs);
else if (map_bankwidth_is_2(map))
r.x = __raw_readw(map->virt + ofs);
else if (map_bankwidth_is_4(map))
r.x = __raw_readl(map->virt + ofs);
#if BITS_PER_LONG >= 64
else if (map_bankwidth_is_8(map))
r.x = __raw_readq(map->virt + ofs);
#define map_read(map, ofs) inline_map_read(map, ofs)
The function map_read will be used in the cmd flash chips command sets driver file drivers/mtd/chips/cfi_cmdset_0001.c(cfi_cmdset_0002.c).
as fas as I understand, the CONFIG_MTD_MAP_BANK_WIDTH_n options are related to physical external bus width. Namely LS1043A's IFC has 16-bit data bus for flash chips connection. Usually, the actual flash bank width is specified in device tree as bank-width parameter. The drivers/mtd/chips/cfi_cmdset_0001.c(cfi_cmdset_0002.c) code uses the bank-width information to issue appropriate width of load/store instructions for flash register access. The main purpose of this is if the flash bank consists of more chips connected in parallel, for example status registers must be read from all the chips. This is what drivers/mtd/chips/cfi_cmdset_0001.c(cfi_cmdset_0002.c) code is doing.
For further reference, I summarize what I've learned about IFC's page read access if IFC_CSORn_NOR[PGRD_EN] = 1:
Typical NOR flash (for example MT28EW used in LS1043A-RDB) has page size of 32 bytes. If IFC_CSORn_NOR[PGRD_EN] = 1 we need the multi-beat read transaction on AMBA bus not to be bigger than 32 bytes. Two useful links for ARM documentation:
What AHB-Lite burst lengths are produced by Cortex-M3 and Cortex-M4?
Combining these articles we have:
1) The AMBA burst length invoked from core is related to an instruction issued.
2) The Cortex-A53 cache linefill always loads 64 bytes, so the cache is unusuable with the NOR flash, 64 bytes is more than the NOR's page size (32 bytes).
3) For Cortex-A53 we must (as I understand) configure MMU to map IFC region as Device memory (how?), than the cache is not used.
4) Now we can use for example ldp instruction to load pair of 64-bit general purpose registers. This should lead to 16 bytes AMBA transaction and hence to 16 bytes page-read from the NOR flash.
5) Maybe we can use the ldp instruction in combination with 128-bit NEON registers to issues 32 bytes AMBA transaction which could match NOR's page size.
Not sure, if this reasoning is correct.