u-boot.git/cmd/sf.c, branch master Unnamed repository; edit this file 'description' to name the repository. cmd: sf: align erase and write on erase block boundary 2025-10-14T14:19:43+00:00 Viorel Suman viorel.suman@nxp.com 2025-09-19T07:01:56+00:00 865f6654226b2b933d1971f86eddb8664ca83a3e Align erase and write on erase block boundary in line with how read was aligned in commit 622b5d35613 ("cmd: sf: Handle unaligned 'update' start offset"). Fixes: 622b5d35613 ("cmd: sf: Handle unaligned 'update' start offset") Signed-off-by: Viorel Suman <viorel.suman@nxp.com> Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car V4H 
Align erase and write on erase block boundary in line with how read was
aligned in commit 622b5d35613 ("cmd: sf: Handle unaligned 'update' start
offset").

Fixes: 622b5d35613 ("cmd: sf: Handle unaligned 'update' start offset")
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # R-Car V4H
cmd: sf: prevent overwriting the reserved memory 2024-09-20T23:38:16+00:00 Prasad Kummari prasad.kummari@amd.com 2024-09-13T07:32:52+00:00 33a4dfc703b43f0e8d4da76411ee3f5aee0c8033 Added LMB API to prevent SF command from overwriting reserved memory areas. The current SPI code does not use LMB APIs for loading data into memory addresses. To resolve this, LMB APIs were added to check the load address of an SF command and ensure it does not overwrite reserved memory addresses. Similar checks are used in TFTP, serial load, and boot code to prevent overwriting reserved memory. Signed-off-by: Prasad Kummari <prasad.kummari@amd.com> Suggested-by: Sughosh Ganu <sughosh.ganu@linaro.org> 
Added LMB API to prevent SF command from overwriting reserved
memory areas. The current SPI code does not use LMB APIs for
loading data into memory addresses. To resolve this, LMB APIs
were added to check the load address of an SF command and ensure it
does not overwrite reserved memory addresses. Similar checks are
used in TFTP, serial load, and boot code to prevent overwriting
reserved memory.

Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Suggested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet" 2024-05-20T19:35:03+00:00 Tom Rini trini@konsulko.com 2024-05-20T19:35:03+00:00 03de305ec48b0bb28554372abb40ccd46dbe0bf9 As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" 2024-05-19T14:16:36+00:00 Tom Rini trini@konsulko.com 2024-05-19T02:20:43+00:00 d678a59d2d719da9e807495b4b021501f2836ca5 When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com> 
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
cmd: Remove <common.h> and add needed includes 2024-05-06T21:05:04+00:00 Tom Rini trini@konsulko.com 2024-04-27T14:10:59+00:00 301bac6047c85e2c5e39929805ca661bb09a7481 Remove <common.h> from all "cmd/" files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com> 
Remove <common.h> from all "cmd/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>
cmd: sf: Fix sf probe crash 2024-04-14T06:49:39+00:00 Weizhao Ouyang o451686892@gmail.com 2024-01-04T11:46:19+00:00 85f3d3de8d3198f216dd3c146a6db6eae3cfff03 Handle the return value of spi_flash_probe_bus_cs() to avoid sf probe crashes. Link: https://lore.kernel.org/all/20240104114619.280513-1-o451686892@gmail.com Signed-off-by: Weizhao Ouyang <o451686892@gmail.com> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Acked-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> 
Handle the return value of spi_flash_probe_bus_cs() to avoid sf probe
crashes.

Link: https://lore.kernel.org/all/20240104114619.280513-1-o451686892@gmail.com
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Acked-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
mtd: spi-nor: Add spi flash lock config option 2023-11-07T12:47:08+00:00 Venkatesh Yadav Abbarapu venkatesh.abbarapu@amd.com 2023-10-03T03:17:13+00:00 188c803d08c6f1744484de6663f7c5d31ef71cfe Provide an explicit configuration option to disable default "lock" of any flash chip which supports locking. By disabling the lock config will save some amount of memory and also don't expose the lock functionality to the users i.e., via sf protect command. Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> Link: https://lore.kernel.org/r/20231003031715.5343-2-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
Provide an explicit configuration option to disable default "lock"
of any flash chip which supports locking. By disabling the lock
config will save some amount of memory and also don't expose the
lock functionality to the users i.e., via sf protect command.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20231003031715.5343-2-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
cmd: Convert existing long help messages to the new macro 2023-10-16T14:24:58+00:00 Tom Rini trini@konsulko.com 2023-10-07T19:13:08+00:00 3616218b5acea74011aea2d14aa1f6366f242849 - Generally we just drop the #ifdef CONFIG_SYS_LONGHELP and endif lines and use U_BOOT_LONGHELP to declare the same variable name as before - In a few places, either rename the variable to follow convention or introduce the variable as it was being done inline before. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
- Generally we just drop the #ifdef CONFIG_SYS_LONGHELP and endif lines
  and use U_BOOT_LONGHELP to declare the same variable name as before
- In a few places, either rename the variable to follow convention or
  introduce the variable as it was being done inline before.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
cmd: sf: Fix the flash_is_unlocked api size parameter 2023-09-21T11:20:12+00:00 Venkatesh Yadav Abbarapu venkatesh.abbarapu@amd.com 2023-09-20T02:54:50+00:00 1290262292473bd89b6beacf2e4e43b27c3c3617 When flash erase is called with size parameter, code is checking if sectors are locked or not. But for checking, the whole device length minus offset is used instead of actual size which should be erased. That's why when only some sectors are locked it is not possible to erase unlocked sectors. The length is calculated as "length = max_chipsize - offset", flash_is_unlocked() api is getting updated with length which is incorrect. Fix this flash_is_unlocked() api by passing the size parameter. ZynqMP> sf erase 0 100000 len=0x8000000 which is flash size size=0x100000 We need to update the size in the flash_is_unlocked() api and not the length. Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20230920025450.6281-1-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
When flash erase is called with size parameter, code is checking
if sectors are locked or not. But for checking, the whole device
length minus offset is used instead of actual size which should
be erased. That's why when only some sectors are locked it is
not possible to erase unlocked sectors.

The length is calculated as "length = max_chipsize - offset",
flash_is_unlocked() api is getting updated with length which is
incorrect. Fix this flash_is_unlocked() api by passing the size
parameter.

ZynqMP> sf erase 0 100000
len=0x8000000 which is flash size
size=0x100000

We need to update the size in the flash_is_unlocked() api and not
the length.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20230920025450.6281-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
cmd: sf/nand: Print and return failure when 0 length is passed 2023-05-31T21:23:01+00:00 Ashok Reddy Soma ashok.reddy.soma@amd.com 2023-05-16T11:52:36+00:00 899fb5aa8becc159b1eb086d8828c4e8eb28f121 For sf commands, when '0' length is passed for erase, update, write or read, there might be undesired results. Ideally '0' length means nothing to do. So print 'ERROR: Invalid size 0' and return cmd failure when length '0' is passed to sf commands. Same thing applies for nand commands also. Example: ZynqMP> sf erase 0 0 ERROR: Invalid size 0 ZynqMP> sf write 10000 0 0 ERROR: Invalid size 0 ZynqMP> sf read 10000 0 0 ERROR: Invalid size 0 ZynqMP> sf update 1000 10000 0 ERROR: Invalid size 0 ZynqMP> Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com> 
For sf commands, when '0' length is passed for erase, update, write or
read, there might be undesired results. Ideally '0' length means nothing to
do.

So print 'ERROR: Invalid size 0' and return cmd failure when length '0' is
passed to sf commands. Same thing applies for nand commands also.

Example:

ZynqMP> sf erase 0 0
ERROR: Invalid size 0
ZynqMP> sf write 10000 0 0
ERROR: Invalid size 0
ZynqMP> sf read 10000 0 0
ERROR: Invalid size 0
ZynqMP> sf update 1000 10000 0
ERROR: Invalid size 0
ZynqMP>

Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>