Skip to content

SF: Migrate to Linux SPI NOR framework

Vignesh R u-boot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 16 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 16 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
Quoted 17 lines
Quoted 11 lines
Quoted 1 line

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.

Quoted 8 lines

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

Read the cover letter in its thread