From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vignesh R Date: Sat, 15 Dec 2018 21:13:12 +0530 Subject: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework In-Reply-To: References: <20181212173228.12281-1-vigneshr@ti.com> <1cd66c4d-d37b-e48b-0a6a-6037e1d255f8@ti.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >>> 2) For BAR support, lets place it as it is and support via spi-nor >> >> Problem is, it not desirable to use BAR as default because its not >> stateless and does not work with all flash parts. OTOH, it seems like 4 >> byte addressing (stateless dedicated opcode or with enter/exit 4 byte >> mode) seems to be standard. >> Also, Linux doesn't support BAR and haven't seen any request for BAR >> support. Why support additional feature and burden of maintaining when >> it may not be needed. >> >> But if you insist, I just have to add BAR support back. > > It's not about insistence, ie how we support since from long and > u-boot bootloader project does in general. bootloader can be some > certain boot difference functionalities unlike Linux, it's better not > to compare u-boot with Linux in all cases. > > Example we have SPI_TX_BYTE which usually not supported in Linux. > Since it's ich controller specific and it require for bootloader to do > byte tx on that specific controller, so we supported. Same for the > case with the BAR, this specific controller(or supported boards) has > been in U-Boot since from long and they do upstream well. So we need > to support BAR in any case or we can find any alternative to work the > same functionalities. (we tried before but ended-up adding BAR) > How about this instead? Lets use 4 byte addressing opcodes as default for >16MB flashes. But if CONFIG_SPI_FLASH_BAR is enabled then, spi-nor layer will use BAR registers for >16MB access instead of 4 byte addressing. I will remove SPI_FLASH_BAR from defconfigs from all boards expect those controllers that really cannot handle 4 byte addressing. From a quick glance it looks following controllers support only 3 byte addresses: stm32_qspi.c ich.c fsl_qspi.c renesas_rpc_spi.c mtk_qspi.c So, except for boards with above controllers, I will remove SPI_FLASH_BAR for all other boards. If there is a regression, then such boards can go back to enabling CONFIG_SPI_FLASH_BAR. AFAIU, above controller HWs(except ich) can support 4 byte addressing but would need to move to spi-mem. Regards Vignesh ex