>>> 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
