SNFI and SPIM-NAND uses different controllers and pins. You can’t use SNFI BL2 on the SPIM-NAND boot path.
Thx. I’m confusing SNFI and NFI, and boot be supperted NFI for spi-nand? (If be supperted NFI, How to config？)
I use openwrt-v21.02.3 to built image， but startup log not show any ‘mtk-snand’ 's infomation，also “MediaTek SPI NAND flash controller driver” be selected.
openwrt v21.02.3 kernel menuconfig GUI:
1 Like
NFI stands for NAND Flash Interface.
NFI controller can support Parallel NAND, SPI-NAND or both.
When NFI controller is interfacing with SPI-NAND, it’s called Serial NAND Flash Interface, i.e. SNFI.
The NFI controller uses its own HW ECC engine, for both Parallel NAND and SPI-NAND.
The On-die ECC engine of SPI-NAND will not be used by SNFI.
In kernel, driver named NFI only interfaces with Parallel NAND:
drivers/mtd/nand/raw/mtk_nand.c
There’s no driver for SNFI in mainline kernel.
The official driver is mtk-snand.
Starting from filogc MT7986, a new SPI master controller was added and it supports spi-mem type QSPI (called SPIM).
When connecting SPI-NAND to this interface, it will be driven by kernel’s standard spi-nand framework.
Since the kernel’s standard spi-nand framework is used, it will enable the On-die ECC, and nothing to do with SNFI.
This boot option is called SPIM-NAND.
BPI-R3 supports booting from SD/eMMC/SPI-NOR/SPIM-NAND, but no SNFI.
SD/eMMC share with one MMC controller, and SPI-NOR/SPIM-NAND/SNFI have their own controller interface.
When the bootstrap switch is set to boot from SPIM-NAND, the bootrom will initialize the SPIM controller and corresponding spi-nand driver using on-die ECC.
Since the page layout of SNFI is different from which of on-die ECC, you can’t connect a SPI-NAND with SNFI page layout to the SPIM-NAND interface. The bootrom won’t recognize it.
1 Like
Thanks for the answer，I got it.
please do not use current ATF-code as i identified a memory-issue (only seen while booting linux, boot till uboot seems fine) with the new ATF-code (common BL2 code for different SoC).
branches from last year should work, but not from (at least july) this year
the issue causes SIGFAULT/SIGSEV in linux userspace at different positions while bootup…mostly before loginprompt.
if using code in my uboot-repo mtk-atf is good (but not support mt7988/bpi-r4),mtk-atf-r4 is broken
I’ve found the cause and suggested a fix here:
1 Like
There is a driver for SNFI in mainline Linux. Afaik MT7981 and MT7988 may not yet be supported, but up to MT7986 it should be fine:
I forgot that.
But we’re not going to use SNFI in future platforms.
Oh, that’s sad. But on MT7981 and MT7988 it is still present, right?
I liked the approach of having the bare SLC NAND cells on an SPI connected IC, and have BCH (which is usually better and faster than any on-die ECC) carried out by the SoC…
Yes. And SNFI may still exists in future platform, but no actual reference design released.
One of the major reason that we retire SNFI is the fact that it increases the difficulty for factory production. The original rom image must be converted by a dedicated BCH tool to add parity code before it can be programmed into flash. Not all manufacturers can handle this correctly.
BTW, I also like this approach…
Thanks for pointing out this.
I’ve checked and found this was introduced by FSEK in May this year.
And this defect also exists in our internal code base 
.
I’ll add this as a a workaround for now and considering also modify the reserved memory in dtsi as the final solution since more and more manufacturers want to use BL32.
atf codebase has been updated
Looks like mt7986 (and maybe others) are unchanged.
I guess the bug is there for all soc (mt7986 was the only one i had a working version to test).
I think the sigsev on r4 is also caused by this as it looks similar
mt7622/mt7981 do not have this file…so i guess they are not affected (but not tested)
mt7988 does not have this issue
code looks similar and effects are too…sigsev on userspace, but i still have them (have ported the change to mt7988 too) on r4…details in the PM thread
oh. I mean there’s no such issue on mtk sdk with kernel 5.4. Not sure for other kernels.
I found that mt7988a.dtsi in openwrt still uses 0x30000 for bl31. That’s out of date:
In contrast, I’ve already changed this in mtk sdk in March this year: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/target/linux/mediatek/files-5.4/arch/arm64/boot/dts/mediatek/mt7988.dtsi#313
/* 320 KiB reserved for ARM Trusted Firmware (BL31 + BL32) */
secmon_reserved: secmon@43000000 {
reg = <0 0x43000000 0 0x50000>;
no-map;
};I use mainline linux but the node is same (if this is wrong we should change it asap)
I don’t think that will cause the sigsevs as the range is before my kernel loadaddress (0x44000000),but i don’t know where kernel unpacks my initrd.
But i can increase size for testing…oh, seems it fixes the sigsevs…such small part of mem causes such big problems
Have not got sdk working with mmc dts, only nand is available for build.
The kernel simply wants to use that RAM for allocation to kernel and userspace at runtime. And that won’t work if everything you write there just “disappears” and all you ever read are 0s.
The mt7988a.dtsi in OpenWrt (which is probably what you copied to your Linux tree, or rather, what Lorenzo copied to his Linux tree where you copied it from) is an older version adapted from MTK SDK. We should just increase the size of the reserved-memory in dts like @hackpascal is suggesting.
Yes,you’re right…makes sense
thought dtsi is already mainline with basics,but it is created by one of the first patches i got from lorenzos tree.
But we should leave the thread for atf/uboot now. Sorry for offtopic.
After internal discussing yesterday, we decide to increase the size of atf reserved-memory to 512KB for all filogic chips.