Re: [PATHv11 07/43] net/lwip: implement wget cmd
Tim, https://github.com/muvarov/u-boot/tree/master_lwip_test_v10 (branch master_lwip_test_v10) Commit 8617b290e79e526119ccef0b0090cb220c78dd34 All later commits are experimental and I'm testing them in the CI. And yes, this series has to apply to the current master without rejects. BR, Maxim. On Wed, 29 Nov 2023 at 02:43, Tom Rini wrote: > On Tue, Nov 28, 2023 at 12:41:44PM -0800, Tim Harvey wrote: > > On Tue, Nov 28, 2023 at 11:12 AM Fabio Estevam > wrote: > > > > > > Hi Maxim, > > > > > > On Tue, Nov 28, 2023 at 4:07 PM Maxim Uvarov > wrote: > > > > > > > From this log it's a little bit different wget output. My version > prints "#" for status. So I guess it's original wget. You can spend time > on debugging it but this code will be replaced. > > > > With my code I tried big iso download and check crc. I did not see > any issues. > > > > > > Thanks for your feedback. > > > > > > I will test wget again after your series gets merged. > > > > > > > Hi Maxim, > > > > Do you have a git repo that we can pull from to test for the wget > failure? > > Note that "b4 am" for this series works currently on top of master, and > getting more general testing on real hardware would be very nice. > > -- > Tom >
Re: [PATCH v2] efi_loader: Make DisconnectController follow the EFI spec
Hi Heinrich,
On Wed, 29 Nov 2023 at 03:26, Heinrich Schuchardt wrote:
>
> On 11/28/23 20:10, Ilias Apalodimas wrote:
> > commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
> > tried to fix the UninstallProtocol interface which must reconnect
> > any controllers it disconnected by calling ConnectController()
> > in case of failure. However, the reconnect functionality was wired in
> > efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
> >
> > As a result some SCT tests started failing.
> > Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
> > - Calls ConnectController for DriverImageHandle1
> > - Calls DisconnectController for DriverImageHandle1 which will
> > disconnect everything apart from TestProtocol4. That will remain
> > open on purpose.
> > - Calls ConnectController for DriverImageHandle2. TestProtocol4
> > which was explicitly preserved was installed wth BY_DRIVER attributes.
> > The new protocol will call DisconnectController since its attributes
> > are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
> > test expects EFI_ACCESS_DENIED which works fine.
> >
> > The problem is that DisconnectController, will eventually call
> > EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
> > this will call CloseProtocol -- the binding protocol is defined in
> > 'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
> > If that close protocol call fails with EFI_NOT_FOUND, the current code
> > will try to mistakenly reconnect all drivers and the subsequent tests
> > that rely on the device being disconnected will fail.
> >
> > Move the reconnection in efi_uninstall_protocol() were it belongs.
> >
> > Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
> > Signed-off-by: Ilias Apalodimas
> > ---
> > Apologies for the fast resend, but since Heinrich reviewed it and
> > we want it in 2024.01 resending
> > Changes since v1:
> > - return ret instead of (ret != EFI_SUCCESS ? ret : EFI_SUCCESS) which does
> > the
> >same thing...
> > - Add a comment about reconnecting all controllers
> > lib/efi_loader/efi_boottime.c | 27 ++-
> > 1 file changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index 0b7579cb5af1..ea711919630b 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -1339,7 +1339,7 @@ static efi_status_t efi_disconnect_all_drivers
> >const efi_guid_t *protocol,
> >efi_handle_t child_handle)
> > {
> > - efi_uintn_t number_of_drivers, tmp;
> > + efi_uintn_t number_of_drivers;
> > efi_handle_t *driver_handle_buffer;
> > efi_status_t r, ret;
> >
> > @@ -1350,27 +1350,13 @@ static efi_status_t efi_disconnect_all_drivers
> > if (!number_of_drivers)
> > return EFI_SUCCESS;
> >
> > - tmp = number_of_drivers;
> > while (number_of_drivers) {
>
> You assume here that drivers can be removed in reverse order.
>
> Please, have a look at CoreDisconnectControllersUsingProtocolInterface()
> in EDK II.
>
> Here the code continues iterating over all connected controllers while
> at least one controller can be removed in each round.
>
> Reverse order is more promising than forward order. But maybe we should
> combine this with retrying like in EDK II.
There are some SCT tests that fail on ConnectController and I was
going to have a look.
But the current patch basically reverts this function as it was prior
to commit 239d59a65e20.
Do we have time to rewrite this before the release? Or should we merge
this and plan to refactor it for 2024.04?
Thanks
/Ilias
>
> Best regards
>
> Heinrich
>
> > - ret = EFI_CALL(efi_disconnect_controller(
> > + r = EFI_CALL(efi_disconnect_controller(
> > handle,
> > driver_handle_buffer[--number_of_drivers],
> > child_handle));
> > - if (ret != EFI_SUCCESS)
> > - goto reconnect;
> > - }
> > -
> > - free(driver_handle_buffer);
> > - return ret;
> > -
> > -reconnect:
> > - /* Reconnect all disconnected drivers */
> > - for (; number_of_drivers < tmp; number_of_drivers++) {
> > - r = EFI_CALL(efi_connect_controller(handle,
> > -
> > _handle_buffer[number_of_drivers],
> > - NULL, true));
> > if (r != EFI_SUCCESS)
> > - EFI_PRINT("Failed to reconnect controller\n");
> > + ret = r;
> > }
> >
> > free(driver_handle_buffer);
> > @@ -1409,6 +1395,13 @@ static efi_status_t efi_uninstall_protocol
> > r = efi_disconnect_all_drivers(handle,
Re: [PATCH 1/1] pico-imx7d: add baseboard SD card boot detect
On 2023-11-29 00:35, Szőke Kálmán Benjamin wrote: Sorry i can not fix it, this is an average e-mail service provider that provides the expected tech level in 2023.Please upgrade your u-boot list website engine to able to support e-mail formats/technologies from 2020s ages. I suggest to use similar what Yocto project has: https://lists.yoctoproject.org/g/main Well, it makes me wonder what are those modern email technologies? Is it HTML? Also, I'm getting "group does not exist" on the link above. Eredeti levél Feladó: Hugo Villeneuve Dátum: 2023 november 29 00:17:51Tárgy: Re: [PATCH 1/1] pico-imx7d: add baseboard SD card boot detectCímzett: Szőke Kálmán Benjamin On Mon, 27 Nov 2023 23:26:08 + (GMT) Szőke Kálmán Benjamin wrote: > It was absolutely conform, i supressed the potentional warning. Once again i say, i will not remove it, if you do not liket it you can remoce as a maintainer. My patch is ready and final. Let's do something to improve i.MX family as a maintainer. I am realy sad to see in last 2-3 years there was no any significats new features for boards since their initial commits. Eredeti levél Feladó: Fabio Estevam Dátum: 2023 november 27 21:39:19Tárgy: Re: [PATCH 1/1] pico-imx7d: add baseboard SD card boot detectCímzett: Szőke Kálmán Benjamin On Mon, Nov 27, 2023 at 4:55 PM Szőke Kálmán Benjamin wrote: > > Unused function parameters should be removed > https://rules.sonarsource.com/c/tag/based-on-misra/RSPEC-1172/ From this same URL: "Exceptions There are some cases when you want to have an unused parameter (usually because the function has to conform to a fixed prototype" which is the case here with your patch, where you need to conform to: int board_mmc_get_env_dev(int devno) Hi, please fix your mailer to wrap lines properly. Hugo Villeneuve.
Re: [PATCH v3 0/9] fs: fat: calculate FAT type based on cluster count
On Wed, 15 Nov 2023 13:44:15 +0100, christian.taedcke-...@weidmueller.com wrote: > From: Christian Taedcke > > > This series fixes an issue where the FAT type (FAT12, FAT16) is not > correctly detected, e.g. when the BPB field BS_FilSysType contains the > valid value "FAT ". > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v2] efi_loader: Make DisconnectController follow the EFI spec
On 11/28/23 20:10, Ilias Apalodimas wrote:
commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
tried to fix the UninstallProtocol interface which must reconnect
any controllers it disconnected by calling ConnectController()
in case of failure. However, the reconnect functionality was wired in
efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
As a result some SCT tests started failing.
Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
- Calls ConnectController for DriverImageHandle1
- Calls DisconnectController for DriverImageHandle1 which will
disconnect everything apart from TestProtocol4. That will remain
open on purpose.
- Calls ConnectController for DriverImageHandle2. TestProtocol4
which was explicitly preserved was installed wth BY_DRIVER attributes.
The new protocol will call DisconnectController since its attributes
are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
test expects EFI_ACCESS_DENIED which works fine.
The problem is that DisconnectController, will eventually call
EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
this will call CloseProtocol -- the binding protocol is defined in
'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
If that close protocol call fails with EFI_NOT_FOUND, the current code
will try to mistakenly reconnect all drivers and the subsequent tests
that rely on the device being disconnected will fail.
Move the reconnection in efi_uninstall_protocol() were it belongs.
Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
Signed-off-by: Ilias Apalodimas
---
Apologies for the fast resend, but since Heinrich reviewed it and
we want it in 2024.01 resending
Changes since v1:
- return ret instead of (ret != EFI_SUCCESS ? ret : EFI_SUCCESS) which does the
same thing...
- Add a comment about reconnecting all controllers
lib/efi_loader/efi_boottime.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 0b7579cb5af1..ea711919630b 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1339,7 +1339,7 @@ static efi_status_t efi_disconnect_all_drivers
const efi_guid_t *protocol,
efi_handle_t child_handle)
{
- efi_uintn_t number_of_drivers, tmp;
+ efi_uintn_t number_of_drivers;
efi_handle_t *driver_handle_buffer;
efi_status_t r, ret;
@@ -1350,27 +1350,13 @@ static efi_status_t efi_disconnect_all_drivers
if (!number_of_drivers)
return EFI_SUCCESS;
- tmp = number_of_drivers;
while (number_of_drivers) {
You assume here that drivers can be removed in reverse order.
Please, have a look at CoreDisconnectControllersUsingProtocolInterface()
in EDK II.
Here the code continues iterating over all connected controllers while
at least one controller can be removed in each round.
Reverse order is more promising than forward order. But maybe we should
combine this with retrying like in EDK II.
Best regards
Heinrich
- ret = EFI_CALL(efi_disconnect_controller(
+ r = EFI_CALL(efi_disconnect_controller(
handle,
driver_handle_buffer[--number_of_drivers],
child_handle));
- if (ret != EFI_SUCCESS)
- goto reconnect;
- }
-
- free(driver_handle_buffer);
- return ret;
-
-reconnect:
- /* Reconnect all disconnected drivers */
- for (; number_of_drivers < tmp; number_of_drivers++) {
- r = EFI_CALL(efi_connect_controller(handle,
-
_handle_buffer[number_of_drivers],
- NULL, true));
if (r != EFI_SUCCESS)
- EFI_PRINT("Failed to reconnect controller\n");
+ ret = r;
}
free(driver_handle_buffer);
@@ -1409,6 +1395,13 @@ static efi_status_t efi_uninstall_protocol
r = efi_disconnect_all_drivers(handle, protocol, NULL);
if (r != EFI_SUCCESS) {
r = EFI_ACCESS_DENIED;
+ /*
+* This will reconnect all controllers of the handle, even ones
+* that were not connected before. This can be done better
+* but we are following the EDKII implementation on this for
+* now
+*/
+ EFI_CALL(efi_connect_controller(handle, NULL, NULL, true));
goto out;
}
/* Close protocol */
--
2.37.2
Re: [PATCH 00/13] Import "string" I/O functions from Linux
On Tue, 14 Nov 2023 14:02:44 +0300, Igor Prusov wrote:
> This series imports generic versions of ioread_rep/iowrite_rep and
> reads/writes from Linux. Some cleanup is done to make sure that all
> platforms have proper defines for implemented functions and there are no
> redefinitions.
>
>
> Igor Prusov (13):
> sandbox: move asm-generic include to the end of file
> x86: Add defines for ins/outs functions
> mips: io.h: Add const to reads functions params
> mips: io.h: Add defines for read/write/in/out functions
> riscv: io.h: Add defines for reads/writes functions
> riscv: io.h: Fix signatures of reads/writes functions
> nios2: io.h: Add defines for ins/outs functions
> powerpc: io.h: Add defines for __raw_{read,write} functions
> xtensa: io.h: Add defines for ins/outs functions
> asm-generic: Import functions from Linux
> spi: meson_spifc_a1: Switch to io{read,write}32_rep()
> treewide: Include linux/io.h instead of asm-generic/io.h
> musb-new: Remove implementation of io.h functions
>
> [...]
Applied to u-boot/next, thanks!
--
Tom
[PATCH v2] pci: Enable dm_pci_map_bar() for 64-bit BARs
Allow dm_pci_map_bar() usage on systems with CONFIG_SYS_PCI_64BIT.
Reviewed-by: Philip Oberfichtner
Signed-off-by: Moritz Fischer
---
Changes from v1:
- Fixed commit message
---
drivers/pci/pci-uclass.c | 11 +++
include/pci.h| 4 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index e0d01f6a85..82308c7477 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1611,6 +1611,17 @@ void *dm_pci_map_bar(struct udevice *dev, int bar,
size_t offset, size_t len,
dm_pci_read_config32(udev, bar, _response);
pci_bus_addr = (pci_addr_t)(bar_response & ~0xf);
+ /*
+* This assumes that dm_pciauto_setup_device() will allocate
+* a 64-bit address if CONFIG_SYS_PCI_64BIT is enabled and
+* the device advertises that it supports it.
+*/
+ if (IS_ENABLED(CONFIG_SYS_PCI_64BIT) &&
+ (bar_response & PCI_BASE_ADDRESS_MEM_TYPE_64)) {
+ dm_pci_read_config32(udev, bar + 4, _response);
+ pci_bus_addr |= (pci_addr_t)bar_response << 32;
+ }
+
if (~((pci_addr_t)0) - pci_bus_addr < offset)
return NULL;
diff --git a/include/pci.h b/include/pci.h
index 2f5eb30b83..0d1ac7b015 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -1350,8 +1350,8 @@ pci_addr_t dm_pci_phys_to_bus(struct udevice *dev,
phys_addr_t addr, size_t len,
*
* Looks up a base address register and finds the physical memory address
* that corresponds to it.
- * Can be used for 32b BARs 0-5 on type 0 functions and for 32b BARs 0-1 on
- * type 1 functions.
+ * Can be used for 32b/64b BARs 0-5 on type 0 functions and for 32b BARs 0-1
+ * on type 1 functions.
* Can also be used on type 0 functions that support Enhanced Allocation for
* 32b/64b BARs. Note that duplicate BEI entries are not supported.
*
--
2.43.0.rc1.413.gea7ed67945-goog
Re: [PATHv11 00/43] net/lwip: add lwip library for the network stack
Hi Tim, On Tue, Nov 28, 2023 at 9:10 PM Tim Harvey wrote: > Fabio, > > You won't see this build issue with the entire series applied... only > with the patches up to and including 'net/lwip: integrate lwIP > library'. My point was there are points in the series where > compilation fails which is not ok. You are right and I agree with your point. I am able to reproduce the build failure at 'net/lwip: integrate lwIP library': In file included from net/lwip/lwip-external/src/core/init.c:38: ./net/lwip/lwip-external/src/include/lwip/opt.h:51:10: fatal error: lwipopts.h: No such file or directory 51 | #include "lwipopts.h" | ^~~~ Thanks
Re: [PATHv11 00/43] net/lwip: add lwip library for the network stack
On Tue, Nov 28, 2023 at 3:21 PM Fabio Estevam wrote: > > Hi Tim and Maxim, > > On Tue, Nov 28, 2023 at 8:05 PM Tim Harvey wrote: > > > Hi Maxim, > > > > I've tried this series on my imx8mm-venice boards and find that basic > > ping/dhcp/tftp breaks: > > u-boot=> net list > > eth0 : ethernet@30be 00:d0:12:78:f8:01 active > > u-boot=> setenv ipaddr 192.168.1.1 > > u-boot=> ping 192.168.1.146 > > eth0: ethernet@30be 00:d0:12:78:f8:01 active > > Using ethernet@30be device > > pinging addr: 192.168.1.146 > > ping_tmo: ping failed; host 192.168.1.146 is not alive > > u-boot=> dhcp > > init already done for ethernet@30be > > dhcp_tmo 20/20 > > dhcp_tmo 19/20 > > dhcp_tmo 18/20 > > dhcp_tmo 17/20 > > dhcp_tmo 16/20 > > dhcp_tmo 15/20 > > dhcp_tmo 14/20 > > dhcp_tmo 13/20 > > dhcp_tmo 12/20 > > dhcp_tmo 11/20 > > dhcp_tmo 10/20 > > dhcp_tmo 9/20 > > dhcp_tmo 8/20 > > dhcp_tmo 7/20 > > dhcp_tmo 6/20 > > dhcp_tmo 5/20 > > dhcp_tmo 4/20 > > dhcp_tmo 3/20 > > dhcp_tmo 2/20 > > dhcp_tmo 1/20 > > dhcp_tmo 0/20 > > DHCP client timeout > > I got the same result on a custom imx8mn-based board. > > > u-boot=> tftpboot $loadaddr venice/Image > > init already done for ethernet@30be > > TFTP from server 192.168.1.146; our IP address is 192.168.1.1 > > Filename 'venice/Image'. > > Load address: 0x4820 > > Loading: > > ^ cntl-c after a minute or so of no output > > > > Is there some basic config here that I may have wrong? > > > > Also, while trying to see if I can determine where things broke I > > noticed there is build breakage starting with 'net/lwip: integrate > > lwIP library' > > In file included from net/lwip/lwip-external/src/core/init.c:38: > > ./net/lwip/lwip-external/src/include/lwip/opt.h:51:10: fatal error: > > lwipopts.h: > > No such file or directory > >51 | #include "lwipopts.h" > > | ^~~~ > > compilation terminated. > > make[2]: *** [scripts/Makefile.build:256: > > net/lwip/lwip-external/src/core/init.o > > ] Error 1 > > make[1]: *** [scripts/Makefile.build:397: net/lwip] Error 2 > > make: *** [Makefile:1858: net] Error 2 > > I haven't noticed this build error here though. I applied Maxim's > series against master. Fabio, You won't see this build issue with the entire series applied... only with the patches up to and including 'net/lwip: integrate lwIP library'. My point was there are points in the series where compilation fails which is not ok. Tim
Re: [PATCH 1/1] pico-imx7d: add baseboard SD card boot detect
Sorry i can not fix it, this is an average e-mail service provider that provides the expected tech level in 2023.Please upgrade your u-boot list website engine to able to support e-mail formats/technologies from 2020s ages. I suggest to use similar what Yocto project has: https://lists.yoctoproject.org/g/main Eredeti levél Feladó: Hugo Villeneuve Dátum: 2023 november 29 00:17:51Tárgy: Re: [PATCH 1/1] pico-imx7d: add baseboard SD card boot detectCímzett: Szőke Kálmán Benjamin On Mon, 27 Nov 2023 23:26:08 + (GMT) Szőke Kálmán Benjamin wrote: > It was absolutely conform, i supressed the potentional warning. Once again i say, i will not remove it, if you do not liket it you can remoce as a maintainer. My patch is ready and final. Let's do something to improve i.MX family as a maintainer. I am realy sad to see in last 2-3 years there was no any significats new features for boards since their initial commits. Eredeti levél Feladó: Fabio Estevam Dátum: 2023 november 27 21:39:19Tárgy: Re: [PATCH 1/1] pico-imx7d: add baseboard SD card boot detectCímzett: Szőke Kálmán Benjamin On Mon, Nov 27, 2023 at 4:55 PM Szőke Kálmán Benjamin wrote: > > Unused function parameters should be removed > https://rules.sonarsource.com/c/tag/based-on-misra/RSPEC-1172/ From this same URL: "Exceptions There are some cases when you want to have an unused parameter (usually because the function has to conform to a fixed prototype" which is the case here with your patch, where you need to conform to: int board_mmc_get_env_dev(int devno) Hi, please fix your mailer to wrap lines properly. Hugo Villeneuve.
Re: [PATHv11 00/43] net/lwip: add lwip library for the network stack
Hi Tim and Maxim, On Tue, Nov 28, 2023 at 8:05 PM Tim Harvey wrote: > Hi Maxim, > > I've tried this series on my imx8mm-venice boards and find that basic > ping/dhcp/tftp breaks: > u-boot=> net list > eth0 : ethernet@30be 00:d0:12:78:f8:01 active > u-boot=> setenv ipaddr 192.168.1.1 > u-boot=> ping 192.168.1.146 > eth0: ethernet@30be 00:d0:12:78:f8:01 active > Using ethernet@30be device > pinging addr: 192.168.1.146 > ping_tmo: ping failed; host 192.168.1.146 is not alive > u-boot=> dhcp > init already done for ethernet@30be > dhcp_tmo 20/20 > dhcp_tmo 19/20 > dhcp_tmo 18/20 > dhcp_tmo 17/20 > dhcp_tmo 16/20 > dhcp_tmo 15/20 > dhcp_tmo 14/20 > dhcp_tmo 13/20 > dhcp_tmo 12/20 > dhcp_tmo 11/20 > dhcp_tmo 10/20 > dhcp_tmo 9/20 > dhcp_tmo 8/20 > dhcp_tmo 7/20 > dhcp_tmo 6/20 > dhcp_tmo 5/20 > dhcp_tmo 4/20 > dhcp_tmo 3/20 > dhcp_tmo 2/20 > dhcp_tmo 1/20 > dhcp_tmo 0/20 > DHCP client timeout I got the same result on a custom imx8mn-based board. > u-boot=> tftpboot $loadaddr venice/Image > init already done for ethernet@30be > TFTP from server 192.168.1.146; our IP address is 192.168.1.1 > Filename 'venice/Image'. > Load address: 0x4820 > Loading: > ^ cntl-c after a minute or so of no output > > Is there some basic config here that I may have wrong? > > Also, while trying to see if I can determine where things broke I > noticed there is build breakage starting with 'net/lwip: integrate > lwIP library' > In file included from net/lwip/lwip-external/src/core/init.c:38: > ./net/lwip/lwip-external/src/include/lwip/opt.h:51:10: fatal error: > lwipopts.h: > No such file or directory >51 | #include "lwipopts.h" > | ^~~~ > compilation terminated. > make[2]: *** [scripts/Makefile.build:256: > net/lwip/lwip-external/src/core/init.o > ] Error 1 > make[1]: *** [scripts/Makefile.build:397: net/lwip] Error 2 > make: *** [Makefile:1858: net] Error 2 I haven't noticed this build error here though. I applied Maxim's series against master.
Re: [PATCH 1/1] pico-imx7d: add baseboard SD card boot detect
On Mon, 27 Nov 2023 23:26:08 + (GMT) Szőke Kálmán Benjamin wrote: > It was absolutely conform, i supressed the potentional warning. Once again i > say, i will not remove it, if you do not liket it you can remoce as a > maintainer. My patch is ready and final. Let's do something to improve i.MX > family as a maintainer. I am realy sad to see in last 2-3 years there was no > any significats new features for boards since their initial commits. > Eredeti levél Feladó: Fabio Estevam Dátum: 2023 > november 27 21:39:19Tárgy: Re: [PATCH 1/1] pico-imx7d: add baseboard SD card > boot detectCímzett: Szőke Kálmán Benjamin On Mon, Nov > 27, 2023 at 4:55 PM Szőke Kálmán Benjamin wrote: > > > Unused function parameters should be removed > https://rules.sonarsource.com/c/tag/based-on-misra/RSPEC-1172/ From this same URL: "Exceptions There are some cases when you want to have an unused parameter (usually because the function has to conform to a fixed prototype" which is the case here with your patch, where you need to conform to: int board_mmc_get_env_dev(int devno) Hi, please fix your mailer to wrap lines properly. Hugo Villeneuve.
Re: [PATHv11 00/43] net/lwip: add lwip library for the network stack
On Mon, Nov 27, 2023 at 5:00 AM Maxim Uvarov wrote: > > Hello, > > Please find updated version of lwip patches. Changes are in the > changelog bellow. > > Thank you, > Maxim. > Hi Maxim, I've tried this series on my imx8mm-venice boards and find that basic ping/dhcp/tftp breaks: u-boot=> net list eth0 : ethernet@30be 00:d0:12:78:f8:01 active u-boot=> setenv ipaddr 192.168.1.1 u-boot=> ping 192.168.1.146 eth0: ethernet@30be 00:d0:12:78:f8:01 active Using ethernet@30be device pinging addr: 192.168.1.146 ping_tmo: ping failed; host 192.168.1.146 is not alive u-boot=> dhcp init already done for ethernet@30be dhcp_tmo 20/20 dhcp_tmo 19/20 dhcp_tmo 18/20 dhcp_tmo 17/20 dhcp_tmo 16/20 dhcp_tmo 15/20 dhcp_tmo 14/20 dhcp_tmo 13/20 dhcp_tmo 12/20 dhcp_tmo 11/20 dhcp_tmo 10/20 dhcp_tmo 9/20 dhcp_tmo 8/20 dhcp_tmo 7/20 dhcp_tmo 6/20 dhcp_tmo 5/20 dhcp_tmo 4/20 dhcp_tmo 3/20 dhcp_tmo 2/20 dhcp_tmo 1/20 dhcp_tmo 0/20 DHCP client timeout u-boot=> tftpboot $loadaddr venice/Image init already done for ethernet@30be TFTP from server 192.168.1.146; our IP address is 192.168.1.1 Filename 'venice/Image'. Load address: 0x4820 Loading: ^ cntl-c after a minute or so of no output Is there some basic config here that I may have wrong? Also, while trying to see if I can determine where things broke I noticed there is build breakage starting with 'net/lwip: integrate lwIP library' In file included from net/lwip/lwip-external/src/core/init.c:38: ./net/lwip/lwip-external/src/include/lwip/opt.h:51:10: fatal error: lwipopts.h: No such file or directory 51 | #include "lwipopts.h" | ^~~~ compilation terminated. make[2]: *** [scripts/Makefile.build:256: net/lwip/lwip-external/src/core/init.o ] Error 1 make[1]: *** [scripts/Makefile.build:397: net/lwip] Error 2 make: *** [Makefile:1858: net] Error 2 make: *** Waiting for unfinished jobs We need to make sure that none of the patches within your series break basic compilation or it makes it difficult for people to bisect issues. Best regards, Tim
RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages
> -Original Message- > From: Ard Biesheuvel > Sent: Tuesday, November 28, 2023 10:08 AM > To: Chiu, Chasel > Cc: Simon Glass ; devicet...@vger.kernel.org; Mark Rutland > ; Rob Herring ; Tan, Lean Sheng > ; lkml ; Dhaval > Sharma ; Brune, Maximilian > ; Yunhui Cui ; > Dong, Guo ; Tom Rini ; ron minnich > ; Guo, Gua ; linux- > a...@vger.kernel.org; U-Boot Mailing List > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory > usages > > You are referring to a 2000 line patch so it is not 100% clear where to look > tbh. > > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel wrote: > > > > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for > related example code. > > > > That refers to a 'memory-allocation' node, right? How does that relate to the > 'reserved-memory' node? > > And crucially, how does this clarify in which way "runtime-code" and "runtime- > data" reservations are being used? > > Since the very beginning of this discussion, I have been asking repeatedly for > examples that describe the wider context in which these reservations are used. > The "runtime" into runtime-code and runtime-data means that these regions have > a special significance to the operating system, not just to the next > bootloader > stage. So I want to understand exactly why it is necessary to describe these > regions in a way where the operating system might be expected to interpret > this > information and act upon it. > I think runtime code and data today are mainly for supporting UEFI runtime services - some BIOS functions for OS to utilize, OS may follow below ACPI spec to treat them as reserved range: https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types Like I mentioned earlier, that PR is still in early phase and has not reflected all the required changes yet, but the idea is to build gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes. UEFI generic Payload has DxeMain integrated, however Memory Types are platform-specific, for example, some platforms may need bigger runtime memory for their implementation, that's why we want such FDT reserved-memory node to tell DxeMain. The Payload flow will be like this: Payload creates built-in default MemoryTypes table -> FDT reserved-memory node to override if required (this also ensures the same memory map cross boots so ACPI S4 works) -> Build gEfiMemoryTypeInformationGuid HOB by "platfom specific" MemoryTypes Table -> DxeMain/GCD to consume this MemoryTypes table and setup memory service -> Install memory types table to UEFI system table.Configuration table... Note: if Payload built-in default MemoryTypes table works fine for the platform, then FDT reserved-memory node does not need to provide such 'usage' compatible strings. (optional) This FDT node could allow flexibility/compatibility without rebuilding Payload binary. Not sure if I answered all your questions, please highlight which area you need more information. Thanks, Chasel > > > > > > -Original Message- > > > From: Chiu, Chasel > > > Sent: Tuesday, November 21, 2023 10:34 AM > > > To: Ard Biesheuvel ; Simon Glass > > > Cc: devicet...@vger.kernel.org; Mark Rutland ; > > > Rob Herring ; Tan, Lean Sheng > > > ; lkml ; > > > Dhaval Sharma ; Brune, Maximilian > > > ; Yunhui Cui > > > ; Dong, Guo ; Tom Rini > > > ; ron minnich ; Guo, Gua > > > ; linux-a...@vger.kernel.org; U-Boot Mailing List > > > ; Chiu, Chasel > > > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory > > > usages > > > > > > > > > Hi Ard, > > > > > > Here is the POC PR for your reference: > > > https://github.com/tianocore/edk2/pull/4969/files#diff- > > > > ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26 > > > 8 > > > Please note that this PR is still in early phase and expected to > > > have significant changes. > > > > > > The idea is that payload entry will create > > > gEfiMemoryTypeInformationGuid HOB with payload default memory types > > > and allow FDT to override if correspond node present. > > > Please let me know if you have questions or suggestions. > > > > > > Thanks, > > > Chasel > > > > > > > > > > -Original Message- > > > > From: Ard Biesheuvel > > > > Sent: Tuesday, November 21, 2023 8:42 AM > > > > To: Simon Glass > > > > Cc: Chiu, Chasel ; > > > > devicet...@vger.kernel.org; Mark Rutland ; > > > > Rob Herring ; Tan, Lean Sheng > > > > ; lkml ; > > > > Dhaval Sharma ; Brune, Maximilian > > > > ; Yunhui Cui > > > > ; Dong, Guo ; Tom > > > > Rini ; ron minnich ; Guo, > > > > Gua ; linux- a...@vger.kernel.org; U-Boot > > > > Mailing List > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common > > > > reserved-memory usages > > > > > > > > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel >
Re: [PATCH v3 31/32] bootstd: Introduce programmatic boot
On Tue, Nov 28, 2023 at 03:14:30PM -0600, Simon Glass wrote: > Hi Tom, > > > On Tue, Nov 28, 2023, 12:21 Tom Rini wrote: > > > On Sat, Nov 18, 2023 at 02:05:19PM -0700, Simon Glass wrote: > > > > > At present bootstd requires CONFIG_CMDLINE to operate. Add a new > > > 'programmatic' boot which can be used when no command line is available. > > > For now it does almost nothing, since most bootmeths require the > > > command line. > > > > > > Signed-off-by: Simon Glass > > > > Overall, this seems fine. The only ask I have really is, can we think > > about how to handle both this case and the case handled by > > cmd/bootmenu.c in a common fashion? To me, one is "show a menu of boot > > options, based on env variables" and one is "show a menu of boot > > options, based on C code" and the "show a menu of boot options" should > > have a lot in common. > > I had not thought about providing a menu with prog boot. I guess I missed how there wasn't a menu with this series and conflated that with one of your other series. > Could we drop this patch from the series for now and apply the others? I > would like to finish and send the follow-on I didn't see any other feedback so yes, I'll be applying this soon'ish. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/4] board: ti: Update to latest board configuration
On 13:40-20231128, Vishal Mahaveer wrote: > This patch series brings in the latest board configurations for > am62 and am62a device. > > Patch "board: ti: am62x/am62ax: Update virtual interrupt allocations > in board config" is needed for booting with the latest TIFS and DM > firmware [1]. > > [1] > https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/log/?h=ti-linux-firmware > SHA: e891ddc65c55bfa7111e4f45834b7c26444dff72 > > > U-boot boot log - > https://gist.github.com/vishalmti/6b38fb80d557478131d5aaed5aeb3596 > > > Vishal Mahaveer (4): > board: ti: am62x/am62ax: Formatting updates to board config files > board: ti: am62ax: Add C7x resource allocation entries to board config > board: ti: am62x/am62ax: Update MCU GPIO interrupt allocation in board > config > board: ti: am62x/am62ax: Update virtual interrupt allocations in board > config > > board/ti/am62ax/rm-cfg.yaml | 522 +++- > board/ti/am62x/rm-cfg.yaml | 481 + > 2 files changed, 396 insertions(+), 607 deletions(-) Sorry, but this is completely confusing. There is no documentation to indicate there is backward compatibility break in firmware. do all users need to upgrade firmware along with board config updates?? what is the minimum firmware version that is supported? is there an ABI version check that should be enforced? Is there absolutely no way for people to use the new firmware and keep their old u-boot? Rather disappointing to see backward compatible breakage occurring this stage of the device. This is not appreciated. Please see if you can fix your firmware to maintain compatibility (as has been the case for year+ now) -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 31/32] bootstd: Introduce programmatic boot
Hi Tom, On Tue, Nov 28, 2023, 12:21 Tom Rini wrote: > On Sat, Nov 18, 2023 at 02:05:19PM -0700, Simon Glass wrote: > > > At present bootstd requires CONFIG_CMDLINE to operate. Add a new > > 'programmatic' boot which can be used when no command line is available. > > For now it does almost nothing, since most bootmeths require the > > command line. > > > > Signed-off-by: Simon Glass > > Overall, this seems fine. The only ask I have really is, can we think > about how to handle both this case and the case handled by > cmd/bootmenu.c in a common fashion? To me, one is "show a menu of boot > options, based on env variables" and one is "show a menu of boot > options, based on C code" and the "show a menu of boot options" should > have a lot in common. > I had not thought about providing a menu with prog boot. Could we drop this patch from the series for now and apply the others? I would like to finish and send the follow-on Regards, Simon > > -- > Tom >
Re: [PATCH 0/9] sysinfo: Expand sysinfo with some more banner information
On Sun, 12 Nov 2023 19:58:20 -0700, Simon Glass wrote: > The show_board_info() function was adjusted to weak so that it could be > entirely replaced with a board-specific implementation. > > The intended way for boards to provide their own information is via a > sysinfo driver. But currently there is no way to show anything other > than the model name. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATHv11 07/43] net/lwip: implement wget cmd
On Tue, Nov 28, 2023 at 12:41:44PM -0800, Tim Harvey wrote: > On Tue, Nov 28, 2023 at 11:12 AM Fabio Estevam wrote: > > > > Hi Maxim, > > > > On Tue, Nov 28, 2023 at 4:07 PM Maxim Uvarov > > wrote: > > > > > From this log it's a little bit different wget output. My version prints > > > "#" for status. So I guess it's original wget. You can spend time on > > > debugging it but this code will be replaced. > > > With my code I tried big iso download and check crc. I did not see any > > > issues. > > > > Thanks for your feedback. > > > > I will test wget again after your series gets merged. > > > > Hi Maxim, > > Do you have a git repo that we can pull from to test for the wget failure? Note that "b4 am" for this series works currently on top of master, and getting more general testing on real hardware would be very nice. -- Tom signature.asc Description: PGP signature
Re: [PATHv11 07/43] net/lwip: implement wget cmd
On Tue, Nov 28, 2023 at 11:12 AM Fabio Estevam wrote: > > Hi Maxim, > > On Tue, Nov 28, 2023 at 4:07 PM Maxim Uvarov wrote: > > > From this log it's a little bit different wget output. My version prints > > "#" for status. So I guess it's original wget. You can spend time on > > debugging it but this code will be replaced. > > With my code I tried big iso download and check crc. I did not see any > > issues. > > Thanks for your feedback. > > I will test wget again after your series gets merged. > Hi Maxim, Do you have a git repo that we can pull from to test for the wget failure? Best regards, Tim
mdt_debug write
Below is the consol log from trying to use mtd_debug write. It returned immediately with a strange success message. root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf fread(): Success I then used the cat command to write to the SPI flash which took a few seconds to execute: root@orangepizero3:~# cat /home/sysadmin/u-boot-sunxi-with-spl.bin > /dev/mtd0 I tried to follow the u-boot documentation on writing the SPI flash but had problems with the write command. When issued it returned immediately. The erase command took about 5 sec to execute. I researched use of mtd commands and got a suggestion to use cat instead, which worked. "root@orangepizero3:~# mtdinfo Count of MTD devices: 1 Present MTD devices: mtd0 Sysfs interface supported: yes root@orangepizero3:~# mtd_debug erase /dev/mtd0 0 0xf Erased 983040 bytes from address 0x in flash root@orangepizero3:~# mtd_debug write /dev/mtd0 0 0xf /home/sysadmin/u-boot-sunxi-with-spl.bin file_to_flash: fread, size 0xf, n 0xf fread(): Success
[PATCH 1/4] board: ti: am62x/am62ax: Formatting updates to board config files
Minor formatting updates to the rm board configuration file for am62x and am62ax boards. Signed-off-by: Vishal Mahaveer --- board/ti/am62ax/rm-cfg.yaml | 454 +--- board/ti/am62x/rm-cfg.yaml | 445 +-- 2 files changed, 326 insertions(+), 573 deletions(-) diff --git a/board/ti/am62ax/rm-cfg.yaml b/board/ti/am62ax/rm-cfg.yaml index 15c4017bda..422f6fef98 100644 --- a/board/ti/am62ax/rm-cfg.yaml +++ b/board/ti/am62ax/rm-cfg.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+ # Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/ # -# Resource management configuration for AM62ax +# Resource management configuration for AM62A # --- @@ -18,234 +18,234 @@ rm-cfg: host_cfg_entries: - #1 host_id: 12 -allowed_atype : 0x2A -allowed_qos : 0x -allowed_orderid : 0x -allowed_priority : 0x -allowed_sched_priority : 0xAA +allowed_atype: 0x2A +allowed_qos: 0x +allowed_orderid: 0x +allowed_priority: 0x +allowed_sched_priority: 0xAA - #2 host_id: 30 -allowed_atype : 0x2A -allowed_qos : 0x -allowed_orderid : 0x -allowed_priority : 0x -allowed_sched_priority : 0xAA +allowed_atype: 0x2A +allowed_qos: 0x +allowed_orderid: 0x +allowed_priority: 0x +allowed_sched_priority: 0xAA - #3 host_id: 36 -allowed_atype : 0x2A -allowed_qos : 0x -allowed_orderid : 0x -allowed_priority : 0x -allowed_sched_priority : 0xAA +allowed_atype: 0x2A +allowed_qos: 0x +allowed_orderid: 0x +allowed_priority: 0x +allowed_sched_priority: 0xAA - #4 host_id: 0 -allowed_atype : 0 -allowed_qos : 0 -allowed_orderid : 0 -allowed_priority : 0 -allowed_sched_priority : 0 +allowed_atype: 0 +allowed_qos: 0 +allowed_orderid: 0 +allowed_priority: 0 +allowed_sched_priority: 0 - #5 host_id: 0 -allowed_atype : 0 -allowed_qos : 0 -allowed_orderid : 0 -allowed_priority : 0 -allowed_sched_priority : 0 +allowed_atype: 0 +allowed_qos: 0 +allowed_orderid: 0 +allowed_priority: 0 +allowed_sched_priority: 0 - #6 host_id: 0 -allowed_atype : 0 -allowed_qos : 0 -allowed_orderid : 0 -allowed_priority : 0 -allowed_sched_priority : 0 +allowed_atype: 0 +allowed_qos: 0 +allowed_orderid: 0 +allowed_priority: 0 +allowed_sched_priority: 0 - #7 host_id: 0 -allowed_atype : 0 -allowed_qos : 0 -allowed_orderid : 0 -allowed_priority : 0 -allowed_sched_priority : 0 +allowed_atype: 0 +allowed_qos: 0 +allowed_orderid: 0 +allowed_priority: 0 +allowed_sched_priority: 0 - #8 host_id: 0 -allowed_atype : 0 -allowed_qos : 0 -allowed_orderid : 0 -allowed_priority : 0 -allowed_sched_priority : 0 +allowed_atype: 0 +allowed_qos: 0 +allowed_orderid: 0 +allowed_priority: 0 +allowed_sched_priority: 0 - #9 host_id: 0 -allowed_atype : 0 -allowed_qos : 0 -allowed_orderid : 0 -allowed_priority : 0 -allowed_sched_priority : 0 +allowed_atype: 0 +allowed_qos: 0 +
[PATCH 3/4] board: ti: am62x/am62ax: Update MCU GPIO interrupt allocation in board config
Share the MCU GPIO interrupts between A53 core and DM R5 core. Allocating 2 instances each to A53 and DM R5. Signed-off-by: Vishal Mahaveer --- board/ti/am62ax/rm-cfg.yaml | 16 ++-- board/ti/am62x/rm-cfg.yaml | 16 ++-- 2 files changed, 28 insertions(+), 4 deletions(-) diff --git a/board/ti/am62ax/rm-cfg.yaml b/board/ti/am62ax/rm-cfg.yaml index 6e15366431..1fb7d64cb8 100644 --- a/board/ti/am62ax/rm-cfg.yaml +++ b/board/ti/am62ax/rm-cfg.yaml @@ -244,7 +244,7 @@ rm-cfg: subhdr: magic: 0x7B25 size: 8 -resasg_entries_size: 1048 +resasg_entries_size: 1064 reserved: 0 resasg_entries: - @@ -285,10 +285,22 @@ rm-cfg: reserved: 0 - start_resource: 0 -num_resource: 4 +num_resource: 2 type: 320 host_id: 12 reserved: 0 +- +start_resource: 2 +num_resource: 2 +type: 320 +host_id: 35 +reserved: 0 +- +start_resource: 2 +num_resource: 2 +type: 320 +host_id: 36 +reserved: 0 - start_resource: 4 num_resource: 4 diff --git a/board/ti/am62x/rm-cfg.yaml b/board/ti/am62x/rm-cfg.yaml index a278675475..5a265ed1e8 100644 --- a/board/ti/am62x/rm-cfg.yaml +++ b/board/ti/am62x/rm-cfg.yaml @@ -244,7 +244,7 @@ rm-cfg: subhdr: magic: 0x7B25 size: 8 -resasg_entries_size: 960 +resasg_entries_size: 976 reserved: 0 resasg_entries: - @@ -285,10 +285,22 @@ rm-cfg: reserved: 0 - start_resource: 0 -num_resource: 4 +num_resource: 2 type: 320 host_id: 12 reserved: 0 +- +start_resource: 2 +num_resource: 2 +type: 320 +host_id: 35 +reserved: 0 +- +start_resource: 2 +num_resource: 2 +type: 320 +host_id: 36 +reserved: 0 - start_resource: 4 num_resource: 4 -- 2.36.1
[PATCH 2/4] board: ti: am62ax: Add C7x resource allocation entries to board config
Update am62ax rm-cfg with allocation entries for C7x core. Following updates are added for C7x: - Share split BCDMA tx and rx channels between DM R5 and C7x - Share rings for split BCDMA tx and rx channels between DM R5 and C7x - Add Global events and Virtual interrupts for C7x Signed-off-by: Vishal Mahaveer --- board/ti/am62ax/rm-cfg.yaml | 46 +++-- 1 file changed, 29 insertions(+), 17 deletions(-) diff --git a/board/ti/am62ax/rm-cfg.yaml b/board/ti/am62ax/rm-cfg.yaml index 422f6fef98..6e15366431 100644 --- a/board/ti/am62ax/rm-cfg.yaml +++ b/board/ti/am62ax/rm-cfg.yaml @@ -24,26 +24,26 @@ rm-cfg: allowed_priority: 0x allowed_sched_priority: 0xAA - #2 -host_id: 30 +host_id: 20 allowed_atype: 0x2A allowed_qos: 0x allowed_orderid: 0x allowed_priority: 0x allowed_sched_priority: 0xAA - #3 -host_id: 36 +host_id: 30 allowed_atype: 0x2A allowed_qos: 0x allowed_orderid: 0x allowed_priority: 0x allowed_sched_priority: 0xAA - #4 -host_id: 0 -allowed_atype: 0 -allowed_qos: 0 -allowed_orderid: 0 -allowed_priority: 0 -allowed_sched_priority: 0 +host_id: 36 +allowed_atype: 0x2A +allowed_qos: 0x +allowed_orderid: 0x +allowed_priority: 0x +allowed_sched_priority: 0xAA - #5 host_id: 0 allowed_atype: 0 @@ -244,7 +244,7 @@ rm-cfg: subhdr: magic: 0x7B25 size: 8 -resasg_entries_size: 1032 +resasg_entries_size: 1048 reserved: 0 resasg_entries: - @@ -323,7 +323,7 @@ rm-cfg: start_resource: 18 num_resource: 6 type: 1677 -host_id: 35 +host_id: 20 reserved: 0 - start_resource: 18 @@ -353,7 +353,7 @@ rm-cfg: start_resource: 72 num_resource: 6 type: 1678 -host_id: 35 +host_id: 20 reserved: 0 - start_resource: 72 @@ -383,7 +383,7 @@ rm-cfg: start_resource: 44 num_resource: 6 type: 1679 -host_id: 35 +host_id: 20 reserved: 0 - start_resource: 44 @@ -413,7 +413,7 @@ rm-cfg: start_resource: 18 num_resource: 6 type: 1696 -host_id: 35 +host_id: 20 reserved: 0 - start_resource: 18 @@ -443,7 +443,7 @@ rm-cfg: start_resource: 18 num_resource: 6 type: 1697 -host_id: 35 +host_id: 20 reserved: 0 - start_resource: 18 @@ -473,7 +473,7 @@ rm-cfg: start_resource: 12 num_resource: 6 type: 1698 -host_id: 35 +host_id: 20 reserved: 0 - start_resource: 12 @@ -495,10 +495,16 @@ rm-cfg: reserved: 0 - start_resource: 6 -num_resource: 34 +num_resource: 26 type: 1802 host_id: 12 reserved: 0 +- +start_resource: 32 +num_resource: 8 +type: 1802 +host_id: 20 +reserved: 0 - start_resource: 44 num_resource: 36 @@ -543,7 +549,13 @@ rm-cfg: reserved: 0 - start_resource: 910 -num_resource: 626 +num_resource: 128 +type: 1805 +host_id: 20 +reserved: 0 +- +start_resource: 1038 +num_resource: 498 type: 1805 host_id: 128 reserved: 0 -- 2.36.1
[PATCH 4/4] board: ti: am62x/am62ax: Update virtual interrupt allocations in board config
Updates as a result of TIFS core now reserving a virtual interrupt for enabling interrupts between DM to TIFS core. Because of this change other virtual interrupt counts decrease by one. Signed-off-by: Vishal Mahaveer --- board/ti/am62ax/rm-cfg.yaml | 22 +++--- board/ti/am62x/rm-cfg.yaml | 20 ++-- 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/board/ti/am62ax/rm-cfg.yaml b/board/ti/am62ax/rm-cfg.yaml index 1fb7d64cb8..b9f3668c07 100644 --- a/board/ti/am62ax/rm-cfg.yaml +++ b/board/ti/am62ax/rm-cfg.yaml @@ -518,14 +518,14 @@ rm-cfg: host_id: 20 reserved: 0 - -start_resource: 44 -num_resource: 36 +start_resource: 45 +num_resource: 35 type: 1802 host_id: 35 reserved: 0 - -start_resource: 44 -num_resource: 36 +start_resource: 45 +num_resource: 35 type: 1802 host_id: 36 reserved: 0 @@ -536,38 +536,38 @@ rm-cfg: host_id: 30 reserved: 0 - -start_resource: 14 +start_resource: 15 num_resource: 512 type: 1805 host_id: 12 reserved: 0 - -start_resource: 526 +start_resource: 527 num_resource: 256 type: 1805 host_id: 35 reserved: 0 - -start_resource: 526 +start_resource: 527 num_resource: 256 type: 1805 host_id: 36 reserved: 0 - -start_resource: 782 +start_resource: 783 num_resource: 128 type: 1805 host_id: 30 reserved: 0 - -start_resource: 910 +start_resource: 911 num_resource: 128 type: 1805 host_id: 20 reserved: 0 - -start_resource: 1038 -num_resource: 498 +start_resource: 1039 +num_resource: 497 type: 1805 host_id: 128 reserved: 0 diff --git a/board/ti/am62x/rm-cfg.yaml b/board/ti/am62x/rm-cfg.yaml index 5a265ed1e8..c06232f6dd 100644 --- a/board/ti/am62x/rm-cfg.yaml +++ b/board/ti/am62x/rm-cfg.yaml @@ -512,14 +512,14 @@ rm-cfg: host_id: 12 reserved: 0 - -start_resource: 44 -num_resource: 36 +start_resource: 45 +num_resource: 35 type: 1802 host_id: 35 reserved: 0 - -start_resource: 44 -num_resource: 36 +start_resource: 45 +num_resource: 35 type: 1802 host_id: 36 reserved: 0 @@ -530,32 +530,32 @@ rm-cfg: host_id: 30 reserved: 0 - -start_resource: 13 +start_resource: 14 num_resource: 512 type: 1805 host_id: 12 reserved: 0 - -start_resource: 525 +start_resource: 526 num_resource: 256 type: 1805 host_id: 35 reserved: 0 - -start_resource: 525 +start_resource: 526 num_resource: 256 type: 1805 host_id: 36 reserved: 0 - -start_resource: 781 +start_resource: 782 num_resource: 128 type: 1805 host_id: 30 reserved: 0 - -start_resource: 909 -num_resource: 627 +start_resource: 910 +num_resource: 626 type: 1805 host_id: 128 reserved: 0 -- 2.36.1
[PATCH 0/4] board: ti: Update to latest board configuration
This patch series brings in the latest board configurations for am62 and am62a device. Patch "board: ti: am62x/am62ax: Update virtual interrupt allocations in board config" is needed for booting with the latest TIFS and DM firmware [1]. [1] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/log/?h=ti-linux-firmware SHA: e891ddc65c55bfa7111e4f45834b7c26444dff72 U-boot boot log - https://gist.github.com/vishalmti/6b38fb80d557478131d5aaed5aeb3596 Vishal Mahaveer (4): board: ti: am62x/am62ax: Formatting updates to board config files board: ti: am62ax: Add C7x resource allocation entries to board config board: ti: am62x/am62ax: Update MCU GPIO interrupt allocation in board config board: ti: am62x/am62ax: Update virtual interrupt allocations in board config board/ti/am62ax/rm-cfg.yaml | 522 +++- board/ti/am62x/rm-cfg.yaml | 481 + 2 files changed, 396 insertions(+), 607 deletions(-) -- 2.36.1
Re: [PATHv11 00/43] net/lwip: add lwip library for the network stack
On Tue, 28 Nov 2023 at 16:37, wrote: > Hi, > > On 27/11/2023 13:56, Maxim Uvarov wrote: > > Hello, > > > > Please find updated version of lwip patches. Changes are in the > > changelog bellow. > > I've ran it on the libretech-cc board, and tried to load grub over tftp, > and I got this strange EFI boot error: > > > U-Boot 2024.01-rc3-00056-g10d85cb3e3 (Nov 28 2023 - 11:17:24 +0100) > libretech-cc > > Model: Libre Computer AML-S905X-CC > SoC: Amlogic Meson GXL (S905X) Revision 21:d (84:2) > DRAM: 2 GiB > > > > Net: eth0: ethernet@c941 > Hit any key to stop autoboot: 0 > => setenv autoload no > => dhcp > ethernet@c941 LPA corruption - aneg restart > ethernet@c941 Waiting for PHY auto negotiation to complete done > Speed: 100, full duplex > eth0: ethernet@c941 3e:a6:23:c0:39:4b active > dhcp_tmo 20/20 > dhcp_tmo 19/20 > DHCP client bound to address 10.34.56.105 > => tftpboot 808 grubaa64.efi > init already done for ethernet@c941 > Speed: 100, full duplex > TFTP from server 10.34.56.1; our IP address is 10.34.56.105 > Filename 'grubaa64.efi'. > Load address: 0x808 > Loading: > done > Bytes transferred = 4288512 (0x417000 hex) > => crc32 808 0x417000 > crc32 for 0808 ... 08496fff ==> c79bc066 > > > > - DHCP OK, > - transfer OK > - CRC32 value OK > > but then trying to run the EFI binary: > > > => bootefi 808 > No EFI system partition > No EFI system partition > Failed to persist EFI variables > No UEFI binary known at 808 > > > > This is what I get on the current master without this patchset: > > > U-Boot 2024.01-rc3-00013-gacae7eb5fe (Nov 28 2023 - 11:29:38 +0100) > libretech-cc > > Model: Libre Computer AML-S905X-CC > SoC: Amlogic Meson GXL (S905X) Revision 21:d (84:2) > DRAM: 2 GiB > > > > Net: eth0: ethernet@c941 > Hit any key to stop autoboot: 0 > => setenv autoload no > => dhcp > ethernet@c941 LPA corruption - aneg restart > ethernet@c941 Waiting for PHY auto negotiation to complete done > Speed: 100, full duplex > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > DHCP client bound to address 10.34.56.105 (1008 ms) > => tftpboot 808 grubaa64.efi > Speed: 100, full duplex > Using ethernet@c941 device > TFTP from server 10.34.56.1; our IP address is 10.34.56.105 > Filename 'grubaa64.efi'. > Load address: 0x808 > Loading: ##T #T T > ## > # > # > # > # > # > # > # > # > # > # > # > ## > 199.2 KiB/s > done > Bytes transferred = 4288512 (417000 hex) > => crc32 808 0x417000 > crc32 for 0808 ... 08496fff ==> c79bc066 > => bootefi 808 > No EFI system partition > No EFI system partition > Failed to persist EFI variables > Booting /grubaa64.efi > Welcome to GRUB! > > > > grub> net_ls_addr > efinet0 3e:a6:23:c0:39:4b 10.34.56.105 > > > > I don't see what's wrong, crc32 is good and env variables are the same: > fileaddr=808 > filesize=417000 > > Neil > > Ok. You provided a small fix for this use case. Will take it into a new version. > > > > > Thank you, > > Maxim. > > > > changelog: > > v11: - v11 is mosly respin of v10 patches with CI error fixes. > > Gitlab CI: > > > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/18368 > > Azure CI: > > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=7366=results > > (Azure CI, which is connected to github. Sometime I can > see > > tftp timeout after some part of download there, but > that can not be > >
Re: [PATHv11 07/43] net/lwip: implement wget cmd
Hi Maxim, On Tue, Nov 28, 2023 at 4:07 PM Maxim Uvarov wrote: > From this log it's a little bit different wget output. My version prints "#" > for status. So I guess it's original wget. You can spend time on debugging it > but this code will be replaced. > With my code I tried big iso download and check crc. I did not see any issues. Thanks for your feedback. I will test wget again after your series gets merged. Cheers
[PATCH v2] efi_loader: Make DisconnectController follow the EFI spec
commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
tried to fix the UninstallProtocol interface which must reconnect
any controllers it disconnected by calling ConnectController()
in case of failure. However, the reconnect functionality was wired in
efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
As a result some SCT tests started failing.
Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
- Calls ConnectController for DriverImageHandle1
- Calls DisconnectController for DriverImageHandle1 which will
disconnect everything apart from TestProtocol4. That will remain
open on purpose.
- Calls ConnectController for DriverImageHandle2. TestProtocol4
which was explicitly preserved was installed wth BY_DRIVER attributes.
The new protocol will call DisconnectController since its attributes
are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
test expects EFI_ACCESS_DENIED which works fine.
The problem is that DisconnectController, will eventually call
EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
this will call CloseProtocol -- the binding protocol is defined in
'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
If that close protocol call fails with EFI_NOT_FOUND, the current code
will try to mistakenly reconnect all drivers and the subsequent tests
that rely on the device being disconnected will fail.
Move the reconnection in efi_uninstall_protocol() were it belongs.
Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
Signed-off-by: Ilias Apalodimas
---
Apologies for the fast resend, but since Heinrich reviewed it and
we want it in 2024.01 resending
Changes since v1:
- return ret instead of (ret != EFI_SUCCESS ? ret : EFI_SUCCESS) which does the
same thing...
- Add a comment about reconnecting all controllers
lib/efi_loader/efi_boottime.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 0b7579cb5af1..ea711919630b 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1339,7 +1339,7 @@ static efi_status_t efi_disconnect_all_drivers
const efi_guid_t *protocol,
efi_handle_t child_handle)
{
- efi_uintn_t number_of_drivers, tmp;
+ efi_uintn_t number_of_drivers;
efi_handle_t *driver_handle_buffer;
efi_status_t r, ret;
@@ -1350,27 +1350,13 @@ static efi_status_t efi_disconnect_all_drivers
if (!number_of_drivers)
return EFI_SUCCESS;
- tmp = number_of_drivers;
while (number_of_drivers) {
- ret = EFI_CALL(efi_disconnect_controller(
+ r = EFI_CALL(efi_disconnect_controller(
handle,
driver_handle_buffer[--number_of_drivers],
child_handle));
- if (ret != EFI_SUCCESS)
- goto reconnect;
- }
-
- free(driver_handle_buffer);
- return ret;
-
-reconnect:
- /* Reconnect all disconnected drivers */
- for (; number_of_drivers < tmp; number_of_drivers++) {
- r = EFI_CALL(efi_connect_controller(handle,
-
_handle_buffer[number_of_drivers],
- NULL, true));
if (r != EFI_SUCCESS)
- EFI_PRINT("Failed to reconnect controller\n");
+ ret = r;
}
free(driver_handle_buffer);
@@ -1409,6 +1395,13 @@ static efi_status_t efi_uninstall_protocol
r = efi_disconnect_all_drivers(handle, protocol, NULL);
if (r != EFI_SUCCESS) {
r = EFI_ACCESS_DENIED;
+ /*
+* This will reconnect all controllers of the handle, even ones
+* that were not connected before. This can be done better
+* but we are following the EDKII implementation on this for
+* now
+*/
+ EFI_CALL(efi_connect_controller(handle, NULL, NULL, true));
goto out;
}
/* Close protocol */
--
2.37.2
Re: [PATHv11 06/43] net/lwip: implement tftp cmd
On Tue, 28 Nov 2023 at 22:34, wrote:
> Hi Maxim,
>
> On 27/11/2023 13:56, Maxim Uvarov wrote:
> > U-Boot recently got support for an alternative network stack using LWIP.
> > Replace tftp command with the LWIP variant while keeping the output and
> > error messages identical.
> >
> > Signed-off-by: Maxim Uvarov
> > ---
> > include/net/lwip.h | 13
> > net/lwip/Makefile | 1 +
> > net/lwip/apps/tftp/Makefile| 7 ++
> > net/lwip/apps/tftp/lwip-tftp.c | 132 +
> > 4 files changed, 153 insertions(+)
> > create mode 100644 net/lwip/apps/tftp/Makefile
> > create mode 100644 net/lwip/apps/tftp/lwip-tftp.c
> >
>
>
>
>
> With:
> ===><==
> diff --git a/net/lwip/apps/tftp/lwip-tftp.c
> b/net/lwip/apps/tftp/lwip-tftp.c
> index 7b384cecf8..1d1b7e8fa5 100644
> --- a/net/lwip/apps/tftp/lwip-tftp.c
> +++ b/net/lwip/apps/tftp/lwip-tftp.c
> @@ -8,6 +8,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "tftp_client.h"
> #include "tftp_server.h"
> @@ -17,6 +19,7 @@
>
> #include
>
> +static char *filename;
> static ulong daddr;
> static ulong size;
> static unsigned int progress_print;
> @@ -38,6 +41,12 @@ static void tftp_close(void *handle)
> ulwip_exit(-1);
> return;
> }
> +
> + if (IS_ENABLED(CONFIG_CMD_BOOTEFI))
> + efi_set_bootdev("Net", "", filename,
> + map_sysmem(daddr - size, 1),
> + size);
> +
> ulwip_exit(0);
> }
>
> @@ -92,6 +101,7 @@ int ulwip_tftp(ulong addr, char *fname)
>
> size = 0;
> daddr = addr;
> + filename = fname;
> server_ip = env_get("serverip");
> if (!server_ip) {
> log_err("error: serverip variable has to be set\n");
> =><==
>
> Loading EFI works again, and you can drop patch 15.
>
> Neil
>
Thanks.
Re: [PATHv11 07/43] net/lwip: implement wget cmd
On Tue, 28 Nov 2023 at 17:32, Fabio Estevam wrote: > Hi Maxim, > > On Mon, Nov 27, 2023 at 5:46 PM Maxim Uvarov > wrote: > > > > U-Boot recently got support for an alternative network stack using LWIP. > > Replace wget command with the LWIP variant while keeping the output and > > error messages identical. > > > > Signed-off-by: Maxim Uvarov > > Do you know whether this wget issue also happens when LWIP is used? > > > https://lore.kernel.org/u-boot/caj+vnu2u9w2nrt6hf1caeq_56sdqviuezudd1iyopdf1cna...@mail.gmail.com/ >From this log it's a little bit different wget output. My version prints "#" for status. So I guess it's original wget. You can spend time on debugging it but this code will be replaced. With my code I tried big iso download and check crc. I did not see any issues. BR, Maxim.
Re: [PATCH v3 31/32] bootstd: Introduce programmatic boot
On Sat, Nov 18, 2023 at 02:05:19PM -0700, Simon Glass wrote: > At present bootstd requires CONFIG_CMDLINE to operate. Add a new > 'programmatic' boot which can be used when no command line is available. > For now it does almost nothing, since most bootmeths require the > command line. > > Signed-off-by: Simon Glass Overall, this seems fine. The only ask I have really is, can we think about how to handle both this case and the case handled by cmd/bootmenu.c in a common fashion? To me, one is "show a menu of boot options, based on env variables" and one is "show a menu of boot options, based on C code" and the "show a menu of boot options" should have a lot in common. -- Tom signature.asc Description: PGP signature
Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages
You are referring to a 2000 line patch so it is not 100% clear where to look tbh. On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel wrote: > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for > related example code. > That refers to a 'memory-allocation' node, right? How does that relate to the 'reserved-memory' node? And crucially, how does this clarify in which way "runtime-code" and "runtime-data" reservations are being used? Since the very beginning of this discussion, I have been asking repeatedly for examples that describe the wider context in which these reservations are used. The "runtime" into runtime-code and runtime-data means that these regions have a special significance to the operating system, not just to the next bootloader stage. So I want to understand exactly why it is necessary to describe these regions in a way where the operating system might be expected to interpret this information and act upon it. > > > -Original Message- > > From: Chiu, Chasel > > Sent: Tuesday, November 21, 2023 10:34 AM > > To: Ard Biesheuvel ; Simon Glass > > Cc: devicet...@vger.kernel.org; Mark Rutland ; Rob > > Herring ; Tan, Lean Sheng ; lkml > > ; Dhaval Sharma ; Brune, > > Maximilian ; Yunhui Cui > > ; Dong, Guo ; Tom Rini > > ; ron minnich ; Guo, Gua > > ; linux-a...@vger.kernel.org; U-Boot Mailing List > b...@lists.denx.de>; Chiu, Chasel > > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory > > usages > > > > > > Hi Ard, > > > > Here is the POC PR for your reference: > > https://github.com/tianocore/edk2/pull/4969/files#diff- > > ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26 > > 8 > > Please note that this PR is still in early phase and expected to have > > significant > > changes. > > > > The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB > > with payload default memory types and allow FDT to override if correspond > > node > > present. > > Please let me know if you have questions or suggestions. > > > > Thanks, > > Chasel > > > > > > > -Original Message- > > > From: Ard Biesheuvel > > > Sent: Tuesday, November 21, 2023 8:42 AM > > > To: Simon Glass > > > Cc: Chiu, Chasel ; devicet...@vger.kernel.org; > > > Mark Rutland ; Rob Herring ; > > > Tan, Lean Sheng ; lkml > > > ; Dhaval Sharma ; > > > Brune, Maximilian ; Yunhui Cui > > > ; Dong, Guo ; Tom Rini > > > ; ron minnich ; Guo, Gua > > > ; linux- a...@vger.kernel.org; U-Boot Mailing List > > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory > > > usages > > > > > > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel > > > > wrote: > > > > > > > > > > > > > > > Hi Ard, > > > > > > > > > > Please see my reply below inline. > > > > > > > > > > Thanks, > > > > > Chasel > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Ard Biesheuvel > > > > > > Sent: Saturday, November 11, 2023 3:04 AM > > > > > > To: Chiu, Chasel > > > > > > Cc: Simon Glass ; devicet...@vger.kernel.org; > > > > > > Mark Rutland ; Rob Herring > > > > > > ; Tan, Lean Sheng ; > > > > > > lkml ; Dhaval Sharma > > > > > > ; Brune, Maximilian > > > > > > ; Yunhui Cui > > > > > > ; Dong, Guo ; Tom > > > > > > Rini ; ron minnich ; > > > > > > Guo, Gua ; linux- a...@vger.kernel.org; > > > > > > U-Boot Mailing List > > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common > > > > > > reserved-memory usages > > > > > > > > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel > > wrote: > > > > > > > > > > > > > > > > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario. > > > > > > > To support ACPI S4/Hibernation, memory map must be consistent > > > > > > > before entering and after resuming from S4, in this case > > > > > > > payload may need to know previous memory map from bootloader > > > > > > > (currently generic payload cannot access platform/bootloader > > > > > > > specific non-volatile data, thus could not save/restore memory > > > > > > > map > > > > > > > information) > > > > > > > > > > > > So how would EDK2 reconstruct the entire EFI memory map from > > > > > > just these unannotated /reserved-memory nodes? The EFI memory > > > > > > map contains much more information than that, and all of it has > > > > > > to match the pre-hibernate situation, right? Can you given an > > > > > > example? > > > > > > > > > > > > > > > Here we listed only typically memory types that may change cross > > > > > different > > > platforms. > > > > > Reserved memory type already can be handled by reserved-memory > > > > > node, > > > and rest of the types usually no need to change cross platforms thus > > > currently we could rely on default in generic payload. > > > > > In the future if we see a need to add new memory types we will > > > > > discuss and > > > add it to FDT schema. > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [PATCH] efi_loader: Make DisconnectController follow the EFI spec
On 28.11.23 18:40, Ilias Apalodimas wrote:
Hi Heinrich
On Tue, 28 Nov 2023 at 18:30, Heinrich Schuchardt wrote:
On 28.11.23 16:45, Ilias Apalodimas wrote:
commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
tried to fix the UninstallProtocol interface which must reconnect
any controllers it disconnected by calling ConnectController()
in case of failure. However, the reconnect functionality was wired in
efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
As a result some SCT tests started failing.
Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
- Calls ConnectController for DriverImageHandle1
- Calls DisconnectController for DriverImageHandle1 which will
disconnect everything apart from TestProtocol4. That will remain
open on purpose.
- Calls ConnectController for DriverImageHandle2. TestProtocol4
which was explicitly preserved was installed wth BY_DRIVER attributes.
The new protocol will call DisconnectController since its attributes
are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
test expects EFI_ACCESS_DENIED which works fine.
The problem is that DisconnectController, will eventually call
EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
this will call CloseProtocol -- the binding protocol is defined in
'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
If that close protocol call fails with EFI_NOT_FOUND, the current code
will try to mistakenly reconnect all drivers and the subsequent tests
that rely on the device being disconnected will fail.
Move the reconnection in efi_uninstall_protocol() were it belongs.
Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
Signed-off-by: Ilias Apalodimas
---
Heinrich this is critical. Although it doesn't break anything on our normal
use cases it does break the ACS testing for SystemReady-IR and I prefer
landing it in -master before the 2024.01 release
Ok
lib/efi_loader/efi_boottime.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 0b7579cb5af1..370eaee8ce1a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1339,7 +1339,7 @@ static efi_status_t efi_disconnect_all_drivers
const efi_guid_t *protocol,
efi_handle_t child_handle)
{
- efi_uintn_t number_of_drivers, tmp;
+ efi_uintn_t number_of_drivers;
efi_handle_t *driver_handle_buffer;
efi_status_t r, ret;
@@ -1350,31 +1350,17 @@ static efi_status_t efi_disconnect_all_drivers
if (!number_of_drivers)
return EFI_SUCCESS;
- tmp = number_of_drivers;
while (number_of_drivers) {
- ret = EFI_CALL(efi_disconnect_controller(
+ r = EFI_CALL(efi_disconnect_controller(
handle,
driver_handle_buffer[--number_of_drivers],
child_handle));
- if (ret != EFI_SUCCESS)
- goto reconnect;
- }
-
- free(driver_handle_buffer);
- return ret;
-
-reconnect:
- /* Reconnect all disconnected drivers */
- for (; number_of_drivers < tmp; number_of_drivers++) {
- r = EFI_CALL(efi_connect_controller(handle,
-
_handle_buffer[number_of_drivers],
DriverHandleBuffer must be a NULL terminated array of handles.
Our implementation of ConnectController() is wrong as it does not
implement this.
Best regards
Heinrich
- NULL, true));
if (r != EFI_SUCCESS)
- EFI_PRINT("Failed to reconnect controller\n");
+ ret = r;
}
free(driver_handle_buffer);
- return ret;
+ return (ret != EFI_SUCCESS ? ret : EFI_SUCCESS);
This will always return ret. Did you want to return another value?
No just ret
}
/**
@@ -1409,6 +1395,7 @@ static efi_status_t efi_uninstall_protocol
r = efi_disconnect_all_drivers(handle, protocol, NULL);
if (r != EFI_SUCCESS) {
r = EFI_ACCESS_DENIED;
+ EFI_CALL(efi_connect_controller(handle, NULL, NULL, true));
Chapter "EFI_BOOT_SERVICES.UninstallProtocolInterface()" of the EFI
specification says: " In addition, all of the drivers that were
disconnected with the boot service DisconnectController() earlier, are
reconnected with the boot service
EFI_BOOT_SERVICES.ConnectController()." What makes you think that
ConnectController() should be called with DriverImageHandle = NULL? I
cannot derive this from the specification.
EDK2 does this as well to reconnect all controllers. Don't we have
the same functionality?
EDK2's CoreDisconnectControllersUsingProtocolInterface()
Re: [PATCH] efi_loader: Make DisconnectController follow the EFI spec
Hi Heinrich
On Tue, 28 Nov 2023 at 18:30, Heinrich Schuchardt wrote:
>
> On 28.11.23 16:45, Ilias Apalodimas wrote:
> > commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
> > tried to fix the UninstallProtocol interface which must reconnect
> > any controllers it disconnected by calling ConnectController()
> > in case of failure. However, the reconnect functionality was wired in
> > efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
> >
> > As a result some SCT tests started failing.
> > Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
> > - Calls ConnectController for DriverImageHandle1
> > - Calls DisconnectController for DriverImageHandle1 which will
> > disconnect everything apart from TestProtocol4. That will remain
> > open on purpose.
> > - Calls ConnectController for DriverImageHandle2. TestProtocol4
> > which was explicitly preserved was installed wth BY_DRIVER attributes.
> > The new protocol will call DisconnectController since its attributes
> > are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
> > test expects EFI_ACCESS_DENIED which works fine.
> >
> > The problem is that DisconnectController, will eventually call
> > EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
> > this will call CloseProtocol -- the binding protocol is defined in
> > 'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
> > If that close protocol call fails with EFI_NOT_FOUND, the current code
> > will try to mistakenly reconnect all drivers and the subsequent tests
> > that rely on the device being disconnected will fail.
>
>
>
> >
> > Move the reconnection in efi_uninstall_protocol() were it belongs.
> >
> > Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
> > Signed-off-by: Ilias Apalodimas
> > ---
> > Heinrich this is critical. Although it doesn't break anything on our normal
> > use cases it does break the ACS testing for SystemReady-IR and I prefer
> > landing it in -master before the 2024.01 release
>
> Ok
>
> >
> > lib/efi_loader/efi_boottime.c | 23 +--
> > 1 file changed, 5 insertions(+), 18 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index 0b7579cb5af1..370eaee8ce1a 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -1339,7 +1339,7 @@ static efi_status_t efi_disconnect_all_drivers
> >const efi_guid_t *protocol,
> >efi_handle_t child_handle)
> > {
> > - efi_uintn_t number_of_drivers, tmp;
> > + efi_uintn_t number_of_drivers;
> > efi_handle_t *driver_handle_buffer;
> > efi_status_t r, ret;
> >
> > @@ -1350,31 +1350,17 @@ static efi_status_t efi_disconnect_all_drivers
> > if (!number_of_drivers)
> > return EFI_SUCCESS;
> >
> > - tmp = number_of_drivers;
> > while (number_of_drivers) {
> > - ret = EFI_CALL(efi_disconnect_controller(
> > + r = EFI_CALL(efi_disconnect_controller(
> > handle,
> > driver_handle_buffer[--number_of_drivers],
> > child_handle));
> > - if (ret != EFI_SUCCESS)
> > - goto reconnect;
> > - }
> > -
> > - free(driver_handle_buffer);
> > - return ret;
> > -
> > -reconnect:
> > - /* Reconnect all disconnected drivers */
> > - for (; number_of_drivers < tmp; number_of_drivers++) {
> > - r = EFI_CALL(efi_connect_controller(handle,
> > -
> > _handle_buffer[number_of_drivers],
> > - NULL, true));
> > if (r != EFI_SUCCESS)
> > - EFI_PRINT("Failed to reconnect controller\n");
> > + ret = r;
> > }
> >
> > free(driver_handle_buffer);
> > - return ret;
> > + return (ret != EFI_SUCCESS ? ret : EFI_SUCCESS);
>
> This will always return ret. Did you want to return another value?
No just ret
> > }
> >
> > /**
> > @@ -1409,6 +1395,7 @@ static efi_status_t efi_uninstall_protocol
> > r = efi_disconnect_all_drivers(handle, protocol, NULL);
> > if (r != EFI_SUCCESS) {
> > r = EFI_ACCESS_DENIED;
> > + EFI_CALL(efi_connect_controller(handle, NULL, NULL, true));
>
> Chapter "EFI_BOOT_SERVICES.UninstallProtocolInterface()" of the EFI
> specification says: " In addition, all of the drivers that were
> disconnected with the boot service DisconnectController() earlier, are
> reconnected with the boot service
> EFI_BOOT_SERVICES.ConnectController()." What makes you think that
> ConnectController() should be called with DriverImageHandle = NULL? I
> cannot derive this from the specification.
EDK2 does this as well to reconnect
[PATCH v2 3/4] arm: mach-k3: Remove non-cached memory map areas
All normal memory areas should be mapped as such.
We added these un-cached holes in our memory map to hack around the
remoteproc driver missing the proper cache maintenance operations.
The problem is having these non-cached memory map areas causes stability
issues later in system operation due to the nature of the K3 coherency
architecture. Plus these are board specific carveouts and instead
should have been added at the board level, not here in the SoC common
code area.
Remove these non-cached memory map areas.
Signed-off-by: Andrew Davis
Reviewed-by: Nishanth Menon
Tested-by: Nishanth Menon
---
arch/arm/mach-k3/arm64-mmu.c | 30 +++---
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 5c858ae0f84..2c2d75d3f41 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -30,13 +30,7 @@ struct mm_region am654_mem_map[] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
- .size = 0x0210UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0xa210UL,
- .phys = 0xa210UL,
- .size = 0x5df0UL,
+ .size = 0x6000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
@@ -81,13 +75,7 @@ struct mm_region j7200_mem_map[] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
- .size = 0x0480UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_NON_SHARE
- }, {
- .virt = 0xa480UL,
- .phys = 0xa480UL,
- .size = 0x5b80UL,
+ .size = 0x6000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
@@ -129,13 +117,7 @@ struct mm_region j721e_mem_map[] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
- .size = 0x1bc0UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_NON_SHARE
- }, {
- .virt = 0xbbc0UL,
- .phys = 0xbbc0UL,
- .size = 0x4440UL,
+ .size = 0x6000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
@@ -151,12 +133,6 @@ struct mm_region j721e_mem_map[] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
- }, {
- .virt = 0x4d8000UL,
- .phys = 0x4d8000UL,
- .size = 0x000200UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_INNER_SHARE
}, {
/* List terminator */
0,
--
2.39.2
[PATCH v2 4/4] arm: mach-k3: Merge initial memory maps
The Device vs Normal memory map is the same for all K3 SoCs. Merge
the SoC specific maps into one.
Signed-off-by: Andrew Davis
Reviewed-by: Nishanth Menon
Tested-by: Nishanth Menon
---
arch/arm/mach-k3/arm64-mmu.c | 228 +--
1 file changed, 2 insertions(+), 226 deletions(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 2c2d75d3f41..b4308205b27 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -12,8 +12,7 @@
#include
#include
-#ifdef CONFIG_SOC_K3_AM654
-struct mm_region am654_mem_map[] = {
+struct mm_region k3_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -52,227 +51,4 @@ struct mm_region am654_mem_map[] = {
}
};
-struct mm_region *mem_map = am654_mem_map;
-#endif /* CONFIG_SOC_K3_AM654 */
-
-#ifdef CONFIG_SOC_K3_J721E
-
-#ifdef CONFIG_SOC_K3_J721E_J7200
-struct mm_region j7200_mem_map[] = {
- {
- .virt = 0x0UL,
- .phys = 0x0UL,
- .size = 0x8000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
- }, {
- .virt = 0x8000UL,
- .phys = 0x8000UL,
- .size = 0x1e78UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0xa000UL,
- .phys = 0xa000UL,
- .size = 0x6000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0x88000UL,
- .phys = 0x88000UL,
- .size = 0x8000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0x5UL,
- .phys = 0x5UL,
- .size = 0x4UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
- }, {
- /* List terminator */
- 0,
- }
-};
-
-struct mm_region *mem_map = j7200_mem_map;
-
-#else /* CONFIG_SOC_K3_J721E_J7200 */
-struct mm_region j721e_mem_map[] = {
- {
- .virt = 0x0UL,
- .phys = 0x0UL,
- .size = 0x8000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
- }, {
- .virt = 0x8000UL,
- .phys = 0x8000UL,
- .size = 0x1e78UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0xa000UL,
- .phys = 0xa000UL,
- .size = 0x6000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0x88000UL,
- .phys = 0x88000UL,
- .size = 0x8000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0x5UL,
- .phys = 0x5UL,
- .size = 0x4UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
- }, {
- /* List terminator */
- 0,
- }
-};
-
-struct mm_region *mem_map = j721e_mem_map;
-#endif /* CONFIG_SOC_K3_J721E_J7200 */
-
-#endif /* CONFIG_SOC_K3_J721E */
-
-#ifdef CONFIG_SOC_K3_J721S2
-struct mm_region j721s2_mem_map[] = {
- {
- .virt = 0x0UL,
- .phys = 0x0UL,
- .size = 0x8000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
- }, {
- .virt = 0x8000UL,
- .phys = 0x8000UL,
- .size = 0x1e78UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0xa000UL,
- .phys = 0xa000UL,
- .size = 0x6000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0x88000UL,
- .phys = 0x88000UL,
- .size = 0x8000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0x5UL,
-
[PATCH v2 1/4] arm: mach-k3: Let the compiler size the mem_map lists
NR_MMU_REGIONS is a copy/paste from another platform that extends
this list later. We do not do that, so let the list be the size
of the initializer list.
Signed-off-by: Andrew Davis
Reviewed-by: Nishanth Menon
Tested-by: Nishanth Menon
---
arch/arm/mach-k3/arm64-mmu.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index e8db5332ae0..d872ed714c4 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -13,11 +13,7 @@
#include
#ifdef CONFIG_SOC_K3_AM654
-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 5)
-
-/* ToDo: Add 64bit IO */
-struct mm_region am654_mem_map[NR_MMU_REGIONS] = {
+struct mm_region am654_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -68,10 +64,7 @@ struct mm_region *mem_map = am654_mem_map;
#ifdef CONFIG_SOC_K3_J721E
#ifdef CONFIG_SOC_K3_J721E_J7200
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 5)
-
-/* ToDo: Add 64bit IO */
-struct mm_region j7200_mem_map[NR_MMU_REGIONS] = {
+struct mm_region j7200_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -119,12 +112,7 @@ struct mm_region j7200_mem_map[NR_MMU_REGIONS] = {
struct mm_region *mem_map = j7200_mem_map;
#else /* CONFIG_SOC_K3_J721E_J7200 */
-
-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 6)
-
-/* ToDo: Add 64bit IO */
-struct mm_region j721e_mem_map[NR_MMU_REGIONS] = {
+struct mm_region j721e_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -181,10 +169,7 @@ struct mm_region *mem_map = j721e_mem_map;
#endif /* CONFIG_SOC_K3_J721E */
#ifdef CONFIG_SOC_K3_J721S2
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 3)
-
-/* ToDo: Add 64bit IO */
-struct mm_region j721s2_mem_map[NR_MMU_REGIONS] = {
+struct mm_region j721s2_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -223,11 +208,7 @@ struct mm_region *mem_map = j721s2_mem_map;
#if defined(CONFIG_SOC_K3_AM625) || defined(CONFIG_SOC_K3_AM62A7)
-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 4)
-
-/* ToDo: Add 64bit IO */
-struct mm_region am62_mem_map[NR_MMU_REGIONS] = {
+struct mm_region am62_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
@@ -272,11 +253,7 @@ struct mm_region *mem_map = am62_mem_map;
#ifdef CONFIG_SOC_K3_AM642
-/* NR_DRAM_BANKS + 32bit IO + 64bit IO + terminator */
-#define NR_MMU_REGIONS (CONFIG_NR_DRAM_BANKS + 4)
-
-/* ToDo: Add 64bit IO */
-struct mm_region am64_mem_map[NR_MMU_REGIONS] = {
+struct mm_region am64_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
--
2.39.2
[PATCH v2 2/4] arm: mach-k3: Do not map ATF and OPTEE regions in MMU
ATF and OPTEE regions may be firewalled from non-secure entities. To
prevent access to this area we leave a hole there in the MMU map. This
is the same idea as [0] but we complete that patch by adding the same
for AM65, J721e, J7200, and J721s2 here.
[0] commit 0688ff3ae23c ("arm: mach-k3: arm64-mmu: do not map ATF and OPTEE
regions in A53 MMU")
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/arm64-mmu.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index d872ed714c4..5c858ae0f84 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -24,7 +24,7 @@ struct mm_region am654_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
- .size = 0x2000UL,
+ .size = 0x1e78UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
@@ -75,7 +75,7 @@ struct mm_region j7200_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
- .size = 0x2000UL,
+ .size = 0x1e78UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
@@ -123,7 +123,7 @@ struct mm_region j721e_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
- .size = 0x2000UL,
+ .size = 0x1e78UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
@@ -180,7 +180,13 @@ struct mm_region j721s2_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
- .size = 0x8000UL,
+ .size = 0x1e78UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0xa000UL,
+ .phys = 0xa000UL,
+ .size = 0x6000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
--
2.39.2
[PATCH v2 0/4] Unify K3 initial memory map
Hello all, This was an RFC as it might still break remoteproc loading, but posted now for merge as worst case this would expose the issue in remoteproc loading better and force someone to go fix it. :) Changes for v2: - Add patch adding firewall MMU hole for Jacinto devices Changes for non-RFC: - Included dependency patch from here[0] into this series - Add Tested-bys - Rebase on latest -next Thanks, Andrew [0] https://lore.kernel.org/all/20231122211218.607757-1-...@ti.com/ Andrew Davis (4): arm: mach-k3: Let the compiler size the mem_map lists arm: mach-k3: Do not map ATF and OPTEE regions in MMU arm: mach-k3: Remove non-cached memory map areas arm: mach-k3: Merge initial memory maps arch/arm/mach-k3/arm64-mmu.c | 271 +-- 1 file changed, 3 insertions(+), 268 deletions(-) -- 2.39.2
Re: [PATCH 2/3] arm: mach-k3: Remove non-cached memory map areas
On 11/27/23 9:47 AM, Nishanth Menon wrote:
On 23:04-20231123, Vignesh Raghavendra wrote:
On 11/23/2023 10:52 PM, Andrew Davis wrote:
@@ -219,16 +177,9 @@ struct mm_region am62_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
- .size = 0x1E78UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
- PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0xA000UL,
- .phys = 0xA000UL,
- .size = 0x6000UL,
+ .size = 0x8000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
-
}, {
.virt = 0x88000UL,
.phys = 0x88000UL,
This causes issues when TF-A region @0x9e78 is firewalled off from
non-secure world. A53 does speculative accesses to this region from EL1
leading to FW exceptions being reported on TIFS log (although A53 itself
doesn't seem to abort)
Hmm... Why not just manage the ones that use TFA in DDR seperately? I
suppose OPTEE will come in the way?
Looks like the no-map is not honored well.. as you were mentioning, a
zephyr style generating the map from dts might be much better, but then
we do support multiple dtbs as well..
OK - I guess we need to leave this cleanup for now.
We can make the same cleanup while leaving the firewall hole in place
(it is in the same spot for all SoCs today so no problem here). I'll
send a v2 with that.
Andrew
Re: [PATCH v4 3/5] gpio: qcom_pmic: fix support for upstream DT
On 28/11/2023 17:30, Caleb Connolly wrote:
Linux devicetrees use the "gpio-ranges" property, add support for
parsing it instead of "gpio-count" so that upstream DTs can be used with
U-Boot.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/dragonboard410c.dts | 3 +--
arch/arm/dts/dragonboard820c.dts | 3 +--
arch/arm/dts/qcs404-evb.dts | 2 +-
arch/arm/dts/sdm845.dtsi | 3 +--
drivers/gpio/qcom_pmic_gpio.c| 38 ++
5 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index c41fee977813..6a4e3ccf17b1 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -170,9 +170,8 @@
compatible = "qcom,pm8916-gpio";
reg = <0xc000 0x400>;
gpio-controller;
- gpio-count = <4>;
+ gpio-ranges = <_gpios 0 0 4>;
#gpio-cells = <2>;
- gpio-bank-name="pmic";
};
};
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index 0d9c9f7a4922..146a0af8aafe 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -132,9 +132,8 @@
compatible = "qcom,pm8994-gpio";
reg = <0xc000 0x400>;
gpio-controller;
- gpio-count = <24>;
+ gpio-ranges = <_gpios 0 0 22>;
#gpio-cells = <2>;
- gpio-bank-name="pm8994.";
};
};
diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
index 84224a8a3d39..3bb580ba4e17 100644
--- a/arch/arm/dts/qcs404-evb.dts
+++ b/arch/arm/dts/qcs404-evb.dts
@@ -378,7 +378,7 @@
compatible = "qcom,pms405-gpio";
reg = <0xc000 0x400>;
gpio-controller;
- gpio-count = <12>;
+ gpio-ranges = <_gpios 0 0 12>;
#gpio-cells = <2>;
gpio-bank-name="pmic";
};
diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
index cd5d890e9a45..a26e9f411ee0 100644
--- a/arch/arm/dts/sdm845.dtsi
+++ b/arch/arm/dts/sdm845.dtsi
@@ -103,9 +103,8 @@
compatible = "qcom,pm8998-gpio";
reg = <0xc000 0x1a00>;
gpio-controller;
- gpio-count = <21>;
+ gpio-ranges = <_gpios 0 0 26>;
#gpio-cells = <2>;
- gpio-bank-name = "pm8998.";
};
};
diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 7b83c67fa464..1adc6566a36d 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -245,23 +245,45 @@ static int qcom_gpio_probe(struct udevice *dev)
return 0;
}
+/*
+ * Parse basic GPIO count specified via the gpio-ranges property
+ * as specified in Linux devicetrees
+ * Returns < 0 on error, otherwise gpio count
+ */
+static int qcom_gpio_of_parse_ranges(struct udevice *dev)
+{
+ int ret;
+ struct ofnode_phandle_args args;
+
+ ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), "gpio-ranges",
+NULL, 3, 0, );
+ if (ret)
+ return log_msg_ret("gpio-ranges", ret);
+
+ return args.args[2];
+}
+
static int qcom_gpio_of_to_plat(struct udevice *dev)
{
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+ int ret;
- uc_priv->gpio_count = dev_read_u32_default(dev, "gpio-count", 0);
- uc_priv->bank_name = dev_read_string(dev, "gpio-bank-name");
- if (uc_priv->bank_name == NULL)
- uc_priv->bank_name = "qcom_pmic";
+ ret = qcom_gpio_of_parse_ranges(dev);
+ if (ret > 0)
+ uc_priv->gpio_count = ret;
+ else
+ return ret;
+
+ uc_priv->bank_name = "pmic";
return 0;
}
static const struct udevice_id qcom_gpio_ids[] = {
- { .compatible = "qcom,pm8916-gpio" },
- { .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
- { .compatible = "qcom,pm8998-gpio" },
- {
Re: [PATCH v4 2/5] gpio: qcom_pmic: rework pwrkey driver into a button driver
On 28/11/2023 17:30, Caleb Connolly wrote:
The power and resin keys were implemented as GPIOs here, but their only
use would be as buttons. Avoid the additional layer of introspection and
rework this driver into a button driver.
While we're here, replace the "qcom,pm8998-pwrkey" compatible with
"qcom,pm8941-pwrkey" to match upstream (Linux).
The dragonboard410c and 820c boards are adjusted to benefit from this
change too, simplify their custom board init code.
Signed-off-by: Caleb Connolly
---
MAINTAINERS | 1 +
arch/arm/dts/dragonboard410c-uboot.dtsi | 11 --
arch/arm/dts/dragonboard410c.dts | 22 ++-
arch/arm/dts/dragonboard820c-uboot.dtsi | 12 --
arch/arm/dts/dragonboard820c.dts | 23 +++-
arch/arm/dts/dragonboard845c-uboot.dtsi | 11 --
arch/arm/dts/dragonboard845c.dts | 4 +
arch/arm/dts/sdm845.dtsi | 23 +++-
arch/arm/dts/starqltechn-uboot.dtsi | 10 --
arch/arm/dts/starqltechn.dts | 20 +--
arch/arm/mach-snapdragon/Kconfig | 3 +
arch/arm/mach-snapdragon/init_sdm845.c | 45 ++-
board/qualcomm/dragonboard410c/dragonboard410c.c | 31 ++---
board/qualcomm/dragonboard820c/dragonboard820c.c | 29 ++--
doc/device-tree-bindings/gpio/pm8916_gpio.txt| 48 ---
drivers/button/Kconfig | 9 ++
drivers/button/Makefile | 1 +
drivers/button/button-qcom-pmic.c| 165 +++
Perhaps you can introduce the button driver first,
and then do the Konfig/mach-snapdragon/DT in a second time
and do the cleanup of the unneeded stuff at the end ?
drivers/gpio/Kconfig | 3 +-
drivers/gpio/qcom_pmic_gpio.c| 104 --
20 files changed, 269 insertions(+), 306 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f6d63c8ab563..8cd102eaa070 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -572,6 +572,7 @@ M: Neil Armstrong
R:Sumit Garg
S:Maintained
F:arch/arm/mach-snapdragon/
+F: drivers/button/button-qcom-pmic.c
F:drivers/clk/qcom/
F:drivers/gpio/msm_gpio.c
F:drivers/mmc/msm_sdhci.c
diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi
b/arch/arm/dts/dragonboard410c-uboot.dtsi
index 3b0bd0ed0a1b..cec64bf80f99 100644
--- a/arch/arm/dts/dragonboard410c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
@@ -42,14 +42,3 @@
gpios = <_gpios 3 0>;
};
};
-
-
-_pon {
- key_vol_down {
- gpios = <_pon 1 0>;
- };
-
- key_power {
- gpios = <_pon 0 0>;
- };
-};
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 9230dd3fd96c..c41fee977813 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -147,11 +147,23 @@
#address-cells = <0x1>;
#size-cells = <0x1>;
-pm8916_pon: pm8916_pon@800 {
- compatible = "qcom,pm8916-pwrkey";
- reg = <0x800 0x96>;
- #gpio-cells = <2>;
- gpio-controller;
+ pon@800 {
+ compatible = "qcom,pm8916-pon";
+ reg = <0x800 0x100>;
+ mode-bootloader = <0x2>;
+ mode-recovery = <0x1>;
+
+ pwrkey {
+ compatible =
"qcom,pm8941-pwrkey";
+ debounce = <15625>;
+ bias-pull-up;
+ };
+
+ pm8916_resin: resin {
+ compatible =
"qcom,pm8941-resin";
+ debounce = <15625>;
+ bias-pull-up;
+ };
};
pm8916_gpios: pm8916_gpios@c000 {
diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi
b/arch/arm/dts/dragonboard820c-uboot.dtsi
index 457728a43ecb..d93c7c1fbdee 100644
--- a/arch/arm/dts/dragonboard820c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard820c-uboot.dtsi
@@ -30,15 +30,3 @@
};
};
};
-
-_pon {
- key_vol_down {
- gpios = <_pon 1 0>;
- label = "key_vol_down";
- };
-
- key_power {
- gpios = <_pon 0 0>;
- label = "key_power";
- };
-};
diff --git a/arch/arm/dts/dragonboard820c.dts
Re: [PATHv11 06/43] net/lwip: implement tftp cmd
Hi Maxim,
On 27/11/2023 13:56, Maxim Uvarov wrote:
U-Boot recently got support for an alternative network stack using LWIP.
Replace tftp command with the LWIP variant while keeping the output and
error messages identical.
Signed-off-by: Maxim Uvarov
---
include/net/lwip.h | 13
net/lwip/Makefile | 1 +
net/lwip/apps/tftp/Makefile| 7 ++
net/lwip/apps/tftp/lwip-tftp.c | 132 +
4 files changed, 153 insertions(+)
create mode 100644 net/lwip/apps/tftp/Makefile
create mode 100644 net/lwip/apps/tftp/lwip-tftp.c
With:
===><==
diff --git a/net/lwip/apps/tftp/lwip-tftp.c b/net/lwip/apps/tftp/lwip-tftp.c
index 7b384cecf8..1d1b7e8fa5 100644
--- a/net/lwip/apps/tftp/lwip-tftp.c
+++ b/net/lwip/apps/tftp/lwip-tftp.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include "tftp_client.h"
#include "tftp_server.h"
@@ -17,6 +19,7 @@
#include
+static char *filename;
static ulong daddr;
static ulong size;
static unsigned int progress_print;
@@ -38,6 +41,12 @@ static void tftp_close(void *handle)
ulwip_exit(-1);
return;
}
+
+ if (IS_ENABLED(CONFIG_CMD_BOOTEFI))
+ efi_set_bootdev("Net", "", filename,
+ map_sysmem(daddr - size, 1),
+ size);
+
ulwip_exit(0);
}
@@ -92,6 +101,7 @@ int ulwip_tftp(ulong addr, char *fname)
size = 0;
daddr = addr;
+ filename = fname;
server_ip = env_get("serverip");
if (!server_ip) {
log_err("error: serverip variable has to be set\n");
=><==
Loading EFI works again, and you can drop patch 15.
Neil
[PATCH v4 5/5] pmic: qcom: dont use dev_read_addr to get USID
Linux DTs stuff a value indicating if the USID is a USID or a GSID in the
reg property, the Linux SPMI driver then reads the two address cells
separately. U-boot's dev_read_addr() doesn't know how to handle this, so
use ofnode_read_u32_index() to get just the USID.
The Qcom pmic driver doesn't have support for GSID handling, so just
ignore the second value for now.
Signed-off-by: Caleb Connolly
---
doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt | 94
drivers/power/pmic/pmic_qcom.c | 13 +++-
2 files changed, 10 insertions(+), 97 deletions(-)
diff --git a/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
b/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
deleted file mode 100644
index eb78e3ae7703..
--- a/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
+++ /dev/null
@@ -1,94 +0,0 @@
- Qualcomm SPMI PMICs multi-function device bindings
-
-The Qualcomm SPMI series presently includes PM8941, PM8841 and PMA8084
-PMICs. These PMICs use a QPNP scheme through SPMI interface.
-QPNP is effectively a partitioning scheme for dividing the SPMI extended
-register space up into logical pieces, and set of fixed register
-locations/definitions within these regions, with some of these regions
-specifically used for interrupt handling.
-
-The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and are
-interfaced to the chip via the SPMI (System Power Management Interface) bus.
-Support for multiple independent functions are implemented by splitting the
-16-bit SPMI slave address space into 256 smaller fixed-size regions, 256 bytes
-each. A function can consume one or more of these fixed-size register regions.
-
-Required properties:
-- compatible: Should contain one of:
- "qcom,pm660",
- "qcom,pm660l",
- "qcom,pm7325",
- "qcom,pm8004",
- "qcom,pm8005",
- "qcom,pm8019",
- "qcom,pm8028",
- "qcom,pm8110",
- "qcom,pm8150",
- "qcom,pm8150b",
- "qcom,pm8150c",
- "qcom,pm8150l",
- "qcom,pm8226",
- "qcom,pm8350c",
- "qcom,pm8841",
- "qcom,pm8901",
- "qcom,pm8909",
- "qcom,pm8916",
- "qcom,pm8941",
- "qcom,pm8950",
- "qcom,pm8953",
- "qcom,pm8994",
- "qcom,pm8998",
- "qcom,pma8084",
- "qcom,pmd9635",
- "qcom,pmi8950",
- "qcom,pmi8962",
- "qcom,pmi8994",
- "qcom,pmi8998",
- "qcom,pmk8002",
- "qcom,pmk8350",
- "qcom,pmr735a",
- "qcom,smb2351",
- or generalized "qcom,spmi-pmic".
-- reg: Specifies the SPMI USID slave address for this device.
- For more information see:
- Documentation/devicetree/bindings/spmi/spmi.yaml
-
-Required properties for peripheral child nodes:
-- compatible: Should contain "qcom,xxx", where "xxx" is a peripheral name.
-
-Optional properties for peripheral child nodes:
-- interrupts: Interrupts are specified as a 4-tuple. For more information
- see:
-
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
-- interrupt-names: Corresponding interrupt name to the interrupts property
-
-Each child node of SPMI slave id represents a function of the PMIC. In the
-example below the rtc device node represents a peripheral of pm8941
-SID = 0. The regulator device node represents a peripheral of pm8941 SID = 1.
-
-Example:
-
- spmi {
- compatible = "qcom,spmi-pmic-arb";
-
- pm8941@0 {
- compatible = "qcom,pm8941", "qcom,spmi-pmic";
- reg = <0x0 SPMI_USID>;
-
- rtc {
- compatible = "qcom,rtc";
- interrupts = <0x0 0x61 0x1
IRQ_TYPE_EDGE_RISING>;
- interrupt-names = "alarm";
- };
- };
-
- pm8941@1 {
- compatible = "qcom,pm8941", "qcom,spmi-pmic";
- reg = <0x1 SPMI_USID>;
-
- regulator {
- compatible = "qcom,regulator";
- regulator-name = "8941_boost";
- };
- };
- };
diff --git a/drivers/power/pmic/pmic_qcom.c b/drivers/power/pmic/pmic_qcom.c
index ad8daf43f06f..f2ac6494811d 100644
--- a/drivers/power/pmic/pmic_qcom.c
+++ b/drivers/power/pmic/pmic_qcom.c
@@ -66,12 +66,19 @@ static const struct udevice_id pmic_qcom_ids[] = {
static int
[PATCH v4 2/5] gpio: qcom_pmic: rework pwrkey driver into a button driver
The power and resin keys were implemented as GPIOs here, but their only
use would be as buttons. Avoid the additional layer of introspection and
rework this driver into a button driver.
While we're here, replace the "qcom,pm8998-pwrkey" compatible with
"qcom,pm8941-pwrkey" to match upstream (Linux).
The dragonboard410c and 820c boards are adjusted to benefit from this
change too, simplify their custom board init code.
Signed-off-by: Caleb Connolly
---
MAINTAINERS | 1 +
arch/arm/dts/dragonboard410c-uboot.dtsi | 11 --
arch/arm/dts/dragonboard410c.dts | 22 ++-
arch/arm/dts/dragonboard820c-uboot.dtsi | 12 --
arch/arm/dts/dragonboard820c.dts | 23 +++-
arch/arm/dts/dragonboard845c-uboot.dtsi | 11 --
arch/arm/dts/dragonboard845c.dts | 4 +
arch/arm/dts/sdm845.dtsi | 23 +++-
arch/arm/dts/starqltechn-uboot.dtsi | 10 --
arch/arm/dts/starqltechn.dts | 20 +--
arch/arm/mach-snapdragon/Kconfig | 3 +
arch/arm/mach-snapdragon/init_sdm845.c | 45 ++-
board/qualcomm/dragonboard410c/dragonboard410c.c | 31 ++---
board/qualcomm/dragonboard820c/dragonboard820c.c | 29 ++--
doc/device-tree-bindings/gpio/pm8916_gpio.txt| 48 ---
drivers/button/Kconfig | 9 ++
drivers/button/Makefile | 1 +
drivers/button/button-qcom-pmic.c| 165 +++
drivers/gpio/Kconfig | 3 +-
drivers/gpio/qcom_pmic_gpio.c| 104 --
20 files changed, 269 insertions(+), 306 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f6d63c8ab563..8cd102eaa070 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -572,6 +572,7 @@ M: Neil Armstrong
R: Sumit Garg
S: Maintained
F: arch/arm/mach-snapdragon/
+F: drivers/button/button-qcom-pmic.c
F: drivers/clk/qcom/
F: drivers/gpio/msm_gpio.c
F: drivers/mmc/msm_sdhci.c
diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi
b/arch/arm/dts/dragonboard410c-uboot.dtsi
index 3b0bd0ed0a1b..cec64bf80f99 100644
--- a/arch/arm/dts/dragonboard410c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
@@ -42,14 +42,3 @@
gpios = <_gpios 3 0>;
};
};
-
-
-_pon {
- key_vol_down {
- gpios = <_pon 1 0>;
- };
-
- key_power {
- gpios = <_pon 0 0>;
- };
-};
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 9230dd3fd96c..c41fee977813 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -147,11 +147,23 @@
#address-cells = <0x1>;
#size-cells = <0x1>;
- pm8916_pon: pm8916_pon@800 {
- compatible = "qcom,pm8916-pwrkey";
- reg = <0x800 0x96>;
- #gpio-cells = <2>;
- gpio-controller;
+ pon@800 {
+ compatible = "qcom,pm8916-pon";
+ reg = <0x800 0x100>;
+ mode-bootloader = <0x2>;
+ mode-recovery = <0x1>;
+
+ pwrkey {
+ compatible =
"qcom,pm8941-pwrkey";
+ debounce = <15625>;
+ bias-pull-up;
+ };
+
+ pm8916_resin: resin {
+ compatible =
"qcom,pm8941-resin";
+ debounce = <15625>;
+ bias-pull-up;
+ };
};
pm8916_gpios: pm8916_gpios@c000 {
diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi
b/arch/arm/dts/dragonboard820c-uboot.dtsi
index 457728a43ecb..d93c7c1fbdee 100644
--- a/arch/arm/dts/dragonboard820c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard820c-uboot.dtsi
@@ -30,15 +30,3 @@
};
};
};
-
-_pon {
- key_vol_down {
- gpios = <_pon 1 0>;
- label = "key_vol_down";
- };
-
- key_power {
- gpios = <_pon 0 0>;
- label = "key_power";
- };
-};
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index ad201d48749c..0d9c9f7a4922 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -109,12 +109,23 @@
[PATCH v4 4/5] spmi: msm: fix register range names
The core and chnl register ranges were swapped on SDM845. Fix it, and
fetch the register ranges by name instead of by index.
Drop the cosmetic "version" variable and clean up the debug logging.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/qcs404-evb.dts| 7 +++--
arch/arm/dts/sdm845.dtsi | 2 +-
doc/device-tree-bindings/spmi/spmi-msm.txt | 26 -
drivers/spmi/spmi-msm.c| 46 --
4 files changed, 23 insertions(+), 58 deletions(-)
diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
index 3bb580ba4e17..cf41e5a33dbe 100644
--- a/arch/arm/dts/qcs404-evb.dts
+++ b/arch/arm/dts/qcs404-evb.dts
@@ -362,9 +362,10 @@
spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
- reg = <0x200f000 0x1000
- 0x240 0x40
- 0x2c0 0x40>;
+ reg = <0x200f000 0x001000>,
+ <0x240 0x80>,
+ <0x2c0 0x80>;
+ reg-names = "core", "chnls", "obsrvr";
#address-cells = <0x1>;
#size-cells = <0x1>;
diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
index a26e9f411ee0..96c9749a52c0 100644
--- a/arch/arm/dts/sdm845.dtsi
+++ b/arch/arm/dts/sdm845.dtsi
@@ -63,7 +63,7 @@
reg = <0xc44 0x1100>,
<0xc60 0x200>,
<0xe60 0x10>;
- reg-names = "cnfg", "core", "obsrvr";
+ reg-names = "core", "chnls", "obsrvr";
#address-cells = <0x1>;
#size-cells = <0x1>;
diff --git a/doc/device-tree-bindings/spmi/spmi-msm.txt
b/doc/device-tree-bindings/spmi/spmi-msm.txt
deleted file mode 100644
index ae47673b768b..
--- a/doc/device-tree-bindings/spmi/spmi-msm.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Qualcomm SPMI arbiter/bus driver
-
-This is bus driver for Qualcomm chips that use SPMI to communicate with PMICs.
-
-Required properties:
-- compatible: "qcom,spmi-pmic-arb"
-- reg: Register block adresses and sizes for various parts of device:
- 1) PMIC arbiter channel mapping base (PMIC_ARB_REG_CHNLn)
- 2) SPMI write command (master) registers (PMIC_ARB_CORE_SW_DEC_CHANNELS)
- 3) SPMI read command (observer) registers (PMIC_ARB_CORE_REGISTERS_OBS)
-
-Optional properties (if not set by parent):
-- #address-cells: 0x1 - childs slave ID address
-- #size-cells: 0x1
-
-All PMICs should be placed as a child nodes of bus arbiter.
-Automatic detection of childs is currently not supported.
-
-Example:
-
-spmi@200f000 {
- compatible = "qcom,spmi-pmic-arb";
- reg = <0x200f800 0x200 0x240 0x40 0x2c0 0x40>;
- #address-cells = <0x1>;
- #size-cells = <0x1>;
-};
diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index 27a035c0a595..5fe8a70abca7 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -70,7 +70,7 @@ enum pmic_arb_channel {
struct msm_spmi_priv {
phys_addr_t arb_chnl; /* ARB channel mapping base */
- phys_addr_t spmi_core; /* SPMI core */
+ phys_addr_t spmi_chnls; /* SPMI channels */
phys_addr_t spmi_obs; /* SPMI observer */
/* SPMI channel map */
uint8_t channel_map[SPMI_MAX_SLAVES][SPMI_MAX_PERIPH];
@@ -95,10 +95,10 @@ static int msm_spmi_write(struct udevice *dev, int usid,
int pid, int off,
/* Disable IRQ mode for the current channel*/
writel(0x0,
- priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CONFIG);
+ priv->spmi_chnls + SPMI_CH_OFFSET(channel) + SPMI_REG_CONFIG);
/* Write single byte */
- writel(val, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_WDATA);
+ writel(val, priv->spmi_chnls + SPMI_CH_OFFSET(channel) +
SPMI_REG_WDATA);
/* Prepare write command */
reg |= SPMI_CMD_EXT_REG_WRITE_LONG << SPMI_CMD_OPCODE_SHIFT;
@@ -113,12 +113,12 @@ static int msm_spmi_write(struct udevice *dev, int usid,
int pid, int off,
ch_offset = SPMI_CH_OFFSET(channel);
/* Send write command */
- writel(reg, priv->spmi_core + SPMI_CH_OFFSET(channel) + SPMI_REG_CMD0);
+ writel(reg, priv->spmi_chnls + SPMI_CH_OFFSET(channel) + SPMI_REG_CMD0);
/* Wait till CMD DONE status */
reg = 0;
while (!reg) {
- reg = readl(priv->spmi_core + SPMI_CH_OFFSET(channel) +
+ reg = readl(priv->spmi_chnls + SPMI_CH_OFFSET(channel) +
SPMI_REG_STATUS);
}
@@ -186,47 +186,37 @@ static struct dm_spmi_ops msm_spmi_ops = {
static int msm_spmi_probe(struct udevice *dev)
{
struct msm_spmi_priv *priv = dev_get_priv(dev);
- phys_addr_t
[PATCH v4 3/5] gpio: qcom_pmic: fix support for upstream DT
Linux devicetrees use the "gpio-ranges" property, add support for
parsing it instead of "gpio-count" so that upstream DTs can be used with
U-Boot.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/dragonboard410c.dts | 3 +--
arch/arm/dts/dragonboard820c.dts | 3 +--
arch/arm/dts/qcs404-evb.dts | 2 +-
arch/arm/dts/sdm845.dtsi | 3 +--
drivers/gpio/qcom_pmic_gpio.c| 38 ++
5 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index c41fee977813..6a4e3ccf17b1 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -170,9 +170,8 @@
compatible = "qcom,pm8916-gpio";
reg = <0xc000 0x400>;
gpio-controller;
- gpio-count = <4>;
+ gpio-ranges = <_gpios 0 0 4>;
#gpio-cells = <2>;
- gpio-bank-name="pmic";
};
};
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index 0d9c9f7a4922..146a0af8aafe 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -132,9 +132,8 @@
compatible = "qcom,pm8994-gpio";
reg = <0xc000 0x400>;
gpio-controller;
- gpio-count = <24>;
+ gpio-ranges = <_gpios 0 0 22>;
#gpio-cells = <2>;
- gpio-bank-name="pm8994.";
};
};
diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
index 84224a8a3d39..3bb580ba4e17 100644
--- a/arch/arm/dts/qcs404-evb.dts
+++ b/arch/arm/dts/qcs404-evb.dts
@@ -378,7 +378,7 @@
compatible = "qcom,pms405-gpio";
reg = <0xc000 0x400>;
gpio-controller;
- gpio-count = <12>;
+ gpio-ranges = <_gpios 0 0 12>;
#gpio-cells = <2>;
gpio-bank-name="pmic";
};
diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
index cd5d890e9a45..a26e9f411ee0 100644
--- a/arch/arm/dts/sdm845.dtsi
+++ b/arch/arm/dts/sdm845.dtsi
@@ -103,9 +103,8 @@
compatible = "qcom,pm8998-gpio";
reg = <0xc000 0x1a00>;
gpio-controller;
- gpio-count = <21>;
+ gpio-ranges = <_gpios 0 0 26>;
#gpio-cells = <2>;
- gpio-bank-name = "pm8998.";
};
};
diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 7b83c67fa464..1adc6566a36d 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -245,23 +245,45 @@ static int qcom_gpio_probe(struct udevice *dev)
return 0;
}
+/*
+ * Parse basic GPIO count specified via the gpio-ranges property
+ * as specified in Linux devicetrees
+ * Returns < 0 on error, otherwise gpio count
+ */
+static int qcom_gpio_of_parse_ranges(struct udevice *dev)
+{
+ int ret;
+ struct ofnode_phandle_args args;
+
+ ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), "gpio-ranges",
+NULL, 3, 0, );
+ if (ret)
+ return log_msg_ret("gpio-ranges", ret);
+
+ return args.args[2];
+}
+
static int qcom_gpio_of_to_plat(struct udevice *dev)
{
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+ int ret;
- uc_priv->gpio_count = dev_read_u32_default(dev, "gpio-count", 0);
- uc_priv->bank_name = dev_read_string(dev, "gpio-bank-name");
- if (uc_priv->bank_name == NULL)
- uc_priv->bank_name = "qcom_pmic";
+ ret = qcom_gpio_of_parse_ranges(dev);
+ if (ret > 0)
+ uc_priv->gpio_count = ret;
+ else
+ return ret;
+
+ uc_priv->bank_name = "pmic";
return 0;
}
static const struct udevice_id qcom_gpio_ids[] = {
- { .compatible = "qcom,pm8916-gpio" },
- { .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
- { .compatible = "qcom,pm8998-gpio" },
- { .compatible = "qcom,pms405-gpio" },
+ { .compatible =
[PATCH v4 1/5] gpio: qcom_pmic: fix silent dev_read_addr downcast
priv->pid is uint32_t, but dev_read_addr() returns a uint64_t on arm64,
with the upper bits being used for error codes. Do error checking before
downcasting to u32 to prevent errors being silently ignored.
Reviewed-by: Sumit Garg
Signed-off-by: Caleb Connolly
---
drivers/gpio/qcom_pmic_gpio.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 65feb453ebc3..e5841f502953 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -221,11 +221,14 @@ static int qcom_gpio_probe(struct udevice *dev)
{
struct qcom_gpio_bank *priv = dev_get_priv(dev);
int reg;
+ u64 pid;
- priv->pid = dev_read_addr(dev);
- if (priv->pid == FDT_ADDR_T_NONE)
+ pid = dev_read_addr(dev);
+ if (pid == FDT_ADDR_T_NONE)
return log_msg_ret("bad address", -EINVAL);
+ priv->pid = pid;
+
/* Do a sanity check */
reg = pmic_reg_read(dev->parent, priv->pid + REG_TYPE);
if (reg != REG_TYPE_VAL)
@@ -328,11 +331,14 @@ static int qcom_pwrkey_probe(struct udevice *dev)
{
struct qcom_gpio_bank *priv = dev_get_priv(dev);
int reg;
+ u64 pid;
- priv->pid = dev_read_addr(dev);
- if (priv->pid == FDT_ADDR_T_NONE)
+ pid = dev_read_addr(dev);
+ if (pid == FDT_ADDR_T_NONE)
return log_msg_ret("bad address", -EINVAL);
+ priv->pid = pid;
+
/* Do a sanity check */
reg = pmic_reg_read(dev->parent, priv->pid + REG_TYPE);
if (reg != 0x1)
--
2.42.1
[PATCH v4 0/5] Qualcomm PMIC fixes
This series addresses some long-standing issues with the SPMI arb
driver, the PMIC, and the PMIC GPIO. It fixes compatibility with
upstream Linux devicetrees, and simplifies pwrkey/resin support by
rewriting the pon driver to be a button driver rather than a GPIO
driver.
Existing users are adjusted to use the new button driver in their
oard init code.
This series is based on the pinctrl [1] and clock [2] cleanup series.
There may be some DTS conflicts applying it standalone.
[1]:
https://lore.kernel.org/u-boot/20231106-b4-qcom-pinctrl-v2-0-406e8d868...@linaro.org/
[2]:
https://lore.kernel.org/u-boot/20231103-b4-qcom-clk-v3-0-8d2d460ec...@linaro.org/
---
Changes in v4:
* Remove some now unsupported DT binding docs
* Fix qcs404 SPMI arb dts
* Link to v3:
https://lore.kernel.org/r/20231114-b4-qcom-dt-compat-v3-0-88a92f8f0...@linaro.org
Changes in v3:
* Remove now-unneeded header includes in dragonboard{410,820}c-uboot.dtsi
* Drop non-standard DTS support from PMIC GPIO driver
* Also remove old gpio-keys nodes from starqltechn-uboot.dtsi
* Link to v2:
https://lore.kernel.org/r/20231108-b4-qcom-dt-compat-v2-0-713233c72...@linaro.org
Changes in v2:
* Avoid using non-standard "label" and "linux,code" properties for
buttons
* Add missing sdm845 DTS parts
* Put button driver in drivers/button
* Link to v1:
https://lore.kernel.org/r/20231106-b4-qcom-dt-compat-v1-0-0ccbb7841...@linaro.org
---
Caleb Connolly (5):
gpio: qcom_pmic: fix silent dev_read_addr downcast
gpio: qcom_pmic: rework pwrkey driver into a button driver
gpio: qcom_pmic: fix support for upstream DT
spmi: msm: fix register range names
pmic: qcom: dont use dev_read_addr to get USID
MAINTAINERS | 1 +
arch/arm/dts/dragonboard410c-uboot.dtsi | 11 --
arch/arm/dts/dragonboard410c.dts | 25 +++-
arch/arm/dts/dragonboard820c-uboot.dtsi | 12 --
arch/arm/dts/dragonboard820c.dts | 26 ++--
arch/arm/dts/dragonboard845c-uboot.dtsi | 11 --
arch/arm/dts/dragonboard845c.dts | 4 +
arch/arm/dts/qcs404-evb.dts | 9 +-
arch/arm/dts/sdm845.dtsi | 28 ++--
arch/arm/dts/starqltechn-uboot.dtsi | 10 --
arch/arm/dts/starqltechn.dts | 20 +--
arch/arm/mach-snapdragon/Kconfig | 3 +
arch/arm/mach-snapdragon/init_sdm845.c | 45 ++-
board/qualcomm/dragonboard410c/dragonboard410c.c | 31 ++---
board/qualcomm/dragonboard820c/dragonboard820c.c | 29 ++--
doc/device-tree-bindings/gpio/pm8916_gpio.txt| 48 ---
doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt | 94 -
doc/device-tree-bindings/spmi/spmi-msm.txt | 26
drivers/button/Kconfig | 9 ++
drivers/button/Makefile | 1 +
drivers/button/button-qcom-pmic.c| 165 +++
drivers/gpio/Kconfig | 3 +-
drivers/gpio/qcom_pmic_gpio.c| 146 +---
drivers/power/pmic/pmic_qcom.c | 13 +-
drivers/spmi/spmi-msm.c | 46 +++
25 files changed, 341 insertions(+), 475 deletions(-)
---
base-commit: d1efa48e205960b15656eb0c13227110895f1cc9
// Caleb (they/them)
Re: [PATCH] efi_loader: Make DisconnectController follow the EFI spec
On 28.11.23 16:45, Ilias Apalodimas wrote:
commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
tried to fix the UninstallProtocol interface which must reconnect
any controllers it disconnected by calling ConnectController()
in case of failure. However, the reconnect functionality was wired in
efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
As a result some SCT tests started failing.
Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
- Calls ConnectController for DriverImageHandle1
- Calls DisconnectController for DriverImageHandle1 which will
disconnect everything apart from TestProtocol4. That will remain
open on purpose.
- Calls ConnectController for DriverImageHandle2. TestProtocol4
which was explicitly preserved was installed wth BY_DRIVER attributes.
The new protocol will call DisconnectController since its attributes
are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
test expects EFI_ACCESS_DENIED which works fine.
The problem is that DisconnectController, will eventually call
EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
this will call CloseProtocol -- the binding protocol is defined in
'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
If that close protocol call fails with EFI_NOT_FOUND, the current code
will try to mistakenly reconnect all drivers and the subsequent tests
that rely on the device being disconnected will fail.
Move the reconnection in efi_uninstall_protocol() were it belongs.
Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
Signed-off-by: Ilias Apalodimas
---
Heinrich this is critical. Although it doesn't break anything on our normal
use cases it does break the ACS testing for SystemReady-IR and I prefer
landing it in -master before the 2024.01 release
Ok
lib/efi_loader/efi_boottime.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 0b7579cb5af1..370eaee8ce1a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1339,7 +1339,7 @@ static efi_status_t efi_disconnect_all_drivers
const efi_guid_t *protocol,
efi_handle_t child_handle)
{
- efi_uintn_t number_of_drivers, tmp;
+ efi_uintn_t number_of_drivers;
efi_handle_t *driver_handle_buffer;
efi_status_t r, ret;
@@ -1350,31 +1350,17 @@ static efi_status_t efi_disconnect_all_drivers
if (!number_of_drivers)
return EFI_SUCCESS;
- tmp = number_of_drivers;
while (number_of_drivers) {
- ret = EFI_CALL(efi_disconnect_controller(
+ r = EFI_CALL(efi_disconnect_controller(
handle,
driver_handle_buffer[--number_of_drivers],
child_handle));
- if (ret != EFI_SUCCESS)
- goto reconnect;
- }
-
- free(driver_handle_buffer);
- return ret;
-
-reconnect:
- /* Reconnect all disconnected drivers */
- for (; number_of_drivers < tmp; number_of_drivers++) {
- r = EFI_CALL(efi_connect_controller(handle,
-
_handle_buffer[number_of_drivers],
- NULL, true));
if (r != EFI_SUCCESS)
- EFI_PRINT("Failed to reconnect controller\n");
+ ret = r;
}
free(driver_handle_buffer);
- return ret;
+ return (ret != EFI_SUCCESS ? ret : EFI_SUCCESS);
This will always return ret. Did you want to return another value?
}
/**
@@ -1409,6 +1395,7 @@ static efi_status_t efi_uninstall_protocol
r = efi_disconnect_all_drivers(handle, protocol, NULL);
if (r != EFI_SUCCESS) {
r = EFI_ACCESS_DENIED;
+ EFI_CALL(efi_connect_controller(handle, NULL, NULL, true));
Chapter "EFI_BOOT_SERVICES.UninstallProtocolInterface()" of the EFI
specification says: " In addition, all of the drivers that were
disconnected with the boot service DisconnectController() earlier, are
reconnected with the boot service
EFI_BOOT_SERVICES.ConnectController()." What makes you think that
ConnectController() should be called with DriverImageHandle = NULL? I
cannot derive this from the specification.
EDK2's CoreDisconnectControllersUsingProtocolInterface() does so. But
shouldn't such behavior be defined in the specification?
We have 4 places where we use EFI_CALL to call efi_connect_controller.
Should we provide an internal function?
Best regards
Heinrich
goto out;
}
/* Close protocol */
--
2.37.2
Re: Please pull u-boot-samsung master
On Tue, Nov 28, 2023 at 12:16:06PM +0900, Minkyu Kang wrote: > Dear Tom, > > The following changes since commit 17e9db18f17b6cad278694d4a61df95e96bdf4f5: > > Merge tag 'doc-2024-01-rc3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-11-11 09:22:54 > -0500) > > are available in the git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-samsung.git master > > for you to fetch changes up to 470682ace1e03a6573d6eef9a00b524d608ddfa7: > > configs: Remove unneeded SYS_CONFIG_NAME from a*y17lte defconfigs > (2023-11-27 18:57:35 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 0/1] Step up as co-maintainer of Tegra SOC platform
On Tue, 31 Oct 2023 20:46:49 +0200, Svyatoslav Ryhel wrote: > I would like to volunteer as Tegra SOC co-maintainer. > > Svyatoslav Ryhel (1): > MAINTAINERS: Step up as co-maintainer of Tegra SOC platform > > MAINTAINERS | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v2 1/3] arm: mvebu: Espressobin: move FDT fixup into a separate function
Hi Robert,
On 11/28/23 16:44, Stefan Roese wrote:
Hi Robert,
On 11/28/23 11:19, Robert Marko wrote:
On Fri, Oct 20, 2023 at 12:21 PM Robert Marko
wrote:
Currently, Esspresobin FDT is being fixed up directly in
ft_board_setup()
which makes it hard to add support for any other board to be fixed up.
So, lets just move the FDT fixup code to a separate function and call it
if compatible matches, there should be no functional change.
Signed-off-by: Robert Marko
Reviewed-by: Stefan Roese
Hi Stefan,
Is there anything I can do to get this series merged?
I just looked at it (again). My recollection was that something was
missing here - so I was waiting for a new version. Does not seem to
be the case though. So I guess I forgot to pull it (sorry for that)
and now with rc3 out it seems a bit too late in the release cycle.
I hope you don't mind that it's postponed to the next merge window.
Seems my memory is not that bad after all. A world CI build fails with
these 3 commits. Could you please have a look?
Completed: 84 total built, 84 newly), duration 1:01:11, rate 0.02
+ ret=100
+ [[ 100 -ne 0 ]]
+ tools/buildman/buildman -o /tmp -seP am33xx at91_kirkwood mvebu omap
-x siemens
Summary of current source for 84 boards (2 threads, 1 job per thread)
aarch64: w+ x240 turris_mox mvebu_ac5_rd eDPU
mvebu_espressobin-88f3720 uDPU clearfog_gt_8k mvebu_db_armada8k
mvebu_mcbin-88f8040 mvebu_puzzle-m801-88f8040 mvebu_crb_cn9130
mvebu_db_cn9130 + mvebu_db-88f3720
arm: w+ am335x_shc am335x_shc_ict am335x_shc_netboot
am335x_shc_sdboot brsmarc1 cm_t43 chiliboard am335x_igep003x am335x_sl50
am43xx_evm_qspiboot am43xx_hs_evm_qspi controlcenterdc db-88f6720
db-88f6820-gp igep00x0 sniper omap3_beagle omap4_panda omap4_sdp4430
+aarch64-linux-ld.bfd: board/Marvell/mvebu_armada-37xx/board.o: in
function `is_edpu_plus':
+board/Marvell/mvebu_armada-37xx/board.c:94:(.text.last_stage_init+0xb4):
undefined reference to `dm_mdio_read'
+make[1]: *** [Makefile:1765: u-boot] Error 139
+make[1]: *** Deleting file 'u-boot'
+make: *** [Makefile:177: sub-make] Error 2
Thanks,
Stefan
Thanks,
Stefan
Regards,
Robert
---
board/Marvell/mvebu_armada-37xx/board.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 04124d8014..1471caa9a6 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -363,18 +363,14 @@ EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT,
last_stage_init);
#endif
#ifdef CONFIG_OF_BOARD_SETUP
-int ft_board_setup(void *blob, struct bd_info *bd)
+static int espressobin_fdt_setup(void *blob)
{
-#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
int ret;
int spi_off;
int parts_off;
int part_off;
/* Fill SPI MTD partitions for Linux kernel on Espressobin */
- if (!of_machine_is_compatible("globalscale,espressobin"))
- return 0;
-
spi_off = fdt_node_offset_by_compatible(blob, -1,
"jedec,spi-nor");
if (spi_off < 0)
return 0;
@@ -459,6 +455,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return 0;
}
+ return 0;
+}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+ if (of_machine_is_compatible("globalscale,espressobin"))
+ return espressobin_fdt_setup(blob);
#endif
return 0;
}
--
2.41.0
Viele Grüße,
Stefan Roese
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH] efi_loader: Make DisconnectController follow the EFI spec
commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
tried to fix the UninstallProtocol interface which must reconnect
any controllers it disconnected by calling ConnectController()
in case of failure. However, the reconnect functionality was wired in
efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
As a result some SCT tests started failing.
Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
- Calls ConnectController for DriverImageHandle1
- Calls DisconnectController for DriverImageHandle1 which will
disconnect everything apart from TestProtocol4. That will remain
open on purpose.
- Calls ConnectController for DriverImageHandle2. TestProtocol4
which was explicitly preserved was installed wth BY_DRIVER attributes.
The new protocol will call DisconnectController since its attributes
are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
test expects EFI_ACCESS_DENIED which works fine.
The problem is that DisconnectController, will eventually call
EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
this will call CloseProtocol -- the binding protocol is defined in
'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
If that close protocol call fails with EFI_NOT_FOUND, the current code
will try to mistakenly reconnect all drivers and the subsequent tests
that rely on the device being disconnected will fail.
Move the reconnection in efi_uninstall_protocol() were it belongs.
Fixes: commit 239d59a65e20 ("efi_loader: reconnect drivers on failure")
Signed-off-by: Ilias Apalodimas
---
Heinrich this is critical. Although it doesn't break anything on our normal
use cases it does break the ACS testing for SystemReady-IR and I prefer
landing it in -master before the 2024.01 release
lib/efi_loader/efi_boottime.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 0b7579cb5af1..370eaee8ce1a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1339,7 +1339,7 @@ static efi_status_t efi_disconnect_all_drivers
const efi_guid_t *protocol,
efi_handle_t child_handle)
{
- efi_uintn_t number_of_drivers, tmp;
+ efi_uintn_t number_of_drivers;
efi_handle_t *driver_handle_buffer;
efi_status_t r, ret;
@@ -1350,31 +1350,17 @@ static efi_status_t efi_disconnect_all_drivers
if (!number_of_drivers)
return EFI_SUCCESS;
- tmp = number_of_drivers;
while (number_of_drivers) {
- ret = EFI_CALL(efi_disconnect_controller(
+ r = EFI_CALL(efi_disconnect_controller(
handle,
driver_handle_buffer[--number_of_drivers],
child_handle));
- if (ret != EFI_SUCCESS)
- goto reconnect;
- }
-
- free(driver_handle_buffer);
- return ret;
-
-reconnect:
- /* Reconnect all disconnected drivers */
- for (; number_of_drivers < tmp; number_of_drivers++) {
- r = EFI_CALL(efi_connect_controller(handle,
-
_handle_buffer[number_of_drivers],
- NULL, true));
if (r != EFI_SUCCESS)
- EFI_PRINT("Failed to reconnect controller\n");
+ ret = r;
}
free(driver_handle_buffer);
- return ret;
+ return (ret != EFI_SUCCESS ? ret : EFI_SUCCESS);
}
/**
@@ -1409,6 +1395,7 @@ static efi_status_t efi_uninstall_protocol
r = efi_disconnect_all_drivers(handle, protocol, NULL);
if (r != EFI_SUCCESS) {
r = EFI_ACCESS_DENIED;
+ EFI_CALL(efi_connect_controller(handle, NULL, NULL, true));
goto out;
}
/* Close protocol */
--
2.37.2
Re: [PATCH v2 1/3] arm: mvebu: Espressobin: move FDT fixup into a separate function
Hi Robert,
On 11/28/23 11:19, Robert Marko wrote:
On Fri, Oct 20, 2023 at 12:21 PM Robert Marko wrote:
Currently, Esspresobin FDT is being fixed up directly in ft_board_setup()
which makes it hard to add support for any other board to be fixed up.
So, lets just move the FDT fixup code to a separate function and call it
if compatible matches, there should be no functional change.
Signed-off-by: Robert Marko
Reviewed-by: Stefan Roese
Hi Stefan,
Is there anything I can do to get this series merged?
I just looked at it (again). My recollection was that something was
missing here - so I was waiting for a new version. Does not seem to
be the case though. So I guess I forgot to pull it (sorry for that)
and now with rc3 out it seems a bit too late in the release cycle.
I hope you don't mind that it's postponed to the next merge window.
Thanks,
Stefan
Regards,
Robert
---
board/Marvell/mvebu_armada-37xx/board.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 04124d8014..1471caa9a6 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -363,18 +363,14 @@ EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, last_stage_init);
#endif
#ifdef CONFIG_OF_BOARD_SETUP
-int ft_board_setup(void *blob, struct bd_info *bd)
+static int espressobin_fdt_setup(void *blob)
{
-#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
int ret;
int spi_off;
int parts_off;
int part_off;
/* Fill SPI MTD partitions for Linux kernel on Espressobin */
- if (!of_machine_is_compatible("globalscale,espressobin"))
- return 0;
-
spi_off = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
if (spi_off < 0)
return 0;
@@ -459,6 +455,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return 0;
}
+ return 0;
+}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+ if (of_machine_is_compatible("globalscale,espressobin"))
+ return espressobin_fdt_setup(blob);
#endif
return 0;
}
--
2.41.0
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATHv11 33/43] configs/am335x_evm_defconfig: inc SPL size
On Tue, Nov 28, 2023 at 03:35:00PM +0600, Maxim Uvarov wrote: > On Mon, 27 Nov 2023 at 22:31, Tom Rini wrote: > > > On Mon, Nov 27, 2023 at 03:52:50PM +, Peter Robinson wrote: > > > On Mon, Nov 27, 2023 at 3:32 PM Maxim Uvarov > > wrote: > > > > > > > > > > > > > > > > On Mon, 27 Nov 2023 at 20:08, Tom Rini wrote: > > > >> > > > >> On Mon, Nov 27, 2023 at 08:06:23PM +0600, Maxim Uvarov wrote: > > > >> > On Mon, 27 Nov 2023 at 19:08, Tom Rini wrote: > > > >> > > > > >> > > On Mon, Nov 27, 2023 at 06:57:16PM +0600, Maxim Uvarov wrote: > > > >> > > > > > >> > > > Increase allowed binary size to fit lwip code. > > > >> > > > > > > >> > > > Signed-off-by: Maxim Uvarov > > > >> > > > --- > > > >> > > > configs/am335x_evm_defconfig | 1 + > > > >> > > > 1 file changed, 1 insertion(+) > > > >> > > > > > > >> > > > diff --git a/configs/am335x_evm_defconfig > > b/configs/am335x_evm_defconfig > > > >> > > > index f048e60f7f..9fd608bd76 100644 > > > >> > > > --- a/configs/am335x_evm_defconfig > > > >> > > > +++ b/configs/am335x_evm_defconfig > > > >> > > > @@ -124,3 +124,4 @@ CONFIG_WDT=y > > > >> > > > CONFIG_DYNAMIC_CRC_TABLE=y > > > >> > > > CONFIG_RSA=y > > > >> > > > CONFIG_LZO=y > > > >> > > > +CONFIG_SPL_MAX_SIZE=0x29000 > > > >> > > > > > >> > > As probably a problem for other platforms you made this change on > > too, > > > >> > > you can't do this. The link limit is here because that's the > > limit the > > > >> > > hardware (and ROM) imposes. > > > >> > > > > > >> > > You might need to either: > > > >> > > - Figure out how to make lwip even tinier for the SPL case > > > >> > > - Limit the old network stack to just for SPL, and a later task > > is to > > > >> > > reduce what's in the old stack to just what's also needed > > within SPL. > > > >> > > > > > >> > > > > > >> > Thanks Tom. All these size changes need to be reviewed. Some of > > them are > > > >> > ok, I think like for x86 or qemu virt, but some of them might not > > work. > > > >> > > > > >> > Question - Do we need networking inside SPL rather than in the main > > binary? > > > >> > Is it a real use case? > > > >> > > > >> Yes, the device supports loading SPL, and then SPL loading U-Boot both > > > >> over USB RNDIS as well as regular physical ethernet. > > > >> > > > >> -- > > > >> Tom > > > > > > > > > > > > That looks like not a production use case. USB + NET + drivers + EXT4 > > + NAND + MTD and everything else and trying to fit into SPL. > > > > With enabling LTO I still need 4k (without dropping current code). > > From one point it's too synthetic use case here and might be a historical > > > > limitation which we will not see on future boards. From the other > > point it will be good to not break it somehow > > > > > > Does this still include the old network code? > > > > > > Also I wonder if we can have a paired down SPL_LWIP option that > > > removes things like PXE and HTTP/wget because none of those would be > > > used in the SPL use case as they're all brand new. > > > > To be clear, I am fine with either "old network stack only for SPL" or > > "figure out how to pair down lwip to just SPL features". In fact having > > said that, the first thing I would suggest is to turn off LTO as it > > makes reading the linker map file harder, increase the size limit for > > this platform, and take a look at what's being linked in and not > > discarded in SPL, for networking, in spl/u-boot-spl.map. Maybe the > > answer is that we just need to be more careful about using > > IS_ENABLED/CONFIG_IS_ENABLED (and obj-$(CONFIG_$(SPL_)FOO)) in the lwip > > series. > > > > -- > > Tom > > > > Yea. If I disable TCP then we get the right size for this board. So for SPL > I think to build without TCP so that ping, dhcp and tftp will still work. > For normal binary TCP will be enabled. For other boards with limits I think > also to disable TCP for now. Yes, that sounds right and also like you need to integrate lwIP more with our Kconfig symbols, PROT_TCP is already there and needs to be obeyed. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/5] gpio: qcom_pmic: rework pwrkey driver into a button driver
>> + pm8998_resin: resin {
>> + compatible =
>> "qcom,pm8941-resin";
>> + debounce = <15625>;
>> + bias-pull-up;
>> + status = "disabled";
>
> Is there a particular reason to keep the resin button disabled by default
> here?
Just following upstream, it's not used on all boards.
>
> -Sumit
>
--
// Caleb (they/them)
[PATCH v1] android_ab: don't ignore ab_control_store return code
ab_control_store() can return an error if writing to disk fails.
In this case, we have to pass the error code to the caller.
Signed-off-by: Alexey Romanov
---
boot/android_ab.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/boot/android_ab.c b/boot/android_ab.c
index 73b55c196c..5a3152dd53 100644
--- a/boot/android_ab.c
+++ b/boot/android_ab.c
@@ -337,7 +337,15 @@ int ab_select_slot(struct blk_desc *dev_desc, struct
disk_partition *part_info,
if (store_needed) {
abc->crc32_le = ab_control_compute_crc(abc);
- ab_control_store(dev_desc, part_info, abc, 0);
+ ret = ab_control_store(dev_desc, part_info, abc, 0);
+ if (ret < 0) {
+#if ANDROID_AB_BACKUP_OFFSET
+ free(backup_abc);
+#endif
+ free(abc);
+ log_err("ANDROID: failed to store boot control block:
%d\n", ret);
+ return ret;
+ }
}
#if ANDROID_AB_BACKUP_OFFSET
@@ -346,8 +354,14 @@ int ab_select_slot(struct blk_desc *dev_desc, struct
disk_partition *part_info,
* to the backup offset
*/
if (memcmp(backup_abc, abc, sizeof(*abc)) != 0) {
- ab_control_store(dev_desc, part_info, abc,
+ ret = ab_control_store(dev_desc, part_info, abc,
ANDROID_AB_BACKUP_OFFSET);
+ if (ret < 0) {
+ free(backup_abc);
+ free(abc);
+ log_err("ANDROID: failed to store boot control block:
%d\n", ret);
+ return ret;
+ }
}
free(backup_abc);
#endif
--
2.39.2
[PATCH RESEND 2/2] configs: andes: add watchdog support fot andes ae350
It adds the ATCWDT200 support for Andes AE350 platform. It also enables wdt command support. Signed-off-by: CL Wang Signed-off-by: Randolph --- configs/ae350_rv32_defconfig | 4 configs/ae350_rv32_spl_defconfig | 4 configs/ae350_rv32_spl_xip_defconfig | 4 configs/ae350_rv32_xip_defconfig | 4 configs/ae350_rv64_defconfig | 4 configs/ae350_rv64_spl_defconfig | 4 configs/ae350_rv64_spl_xip_defconfig | 4 configs/ae350_rv64_xip_defconfig | 4 8 files changed, 32 insertions(+) diff --git a/configs/ae350_rv32_defconfig b/configs/ae350_rv32_defconfig index 06cd972a0d..a32672f8ed 100644 --- a/configs/ae350_rv32_defconfig +++ b/configs/ae350_rv32_defconfig @@ -22,6 +22,7 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -48,3 +49,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y \ No newline at end of file diff --git a/configs/ae350_rv32_spl_defconfig b/configs/ae350_rv32_spl_defconfig index f469d5bb2b..e09f878329 100644 --- a/configs/ae350_rv32_spl_defconfig +++ b/configs/ae350_rv32_spl_defconfig @@ -32,6 +32,7 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -57,3 +58,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv32_spl_xip_defconfig b/configs/ae350_rv32_spl_xip_defconfig index 9672a19c23..850e67a0d9 100644 --- a/configs/ae350_rv32_spl_xip_defconfig +++ b/configs/ae350_rv32_spl_xip_defconfig @@ -33,6 +33,7 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -58,3 +59,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv32_xip_defconfig b/configs/ae350_rv32_xip_defconfig index b90200a97e..8745ac4c07 100644 --- a/configs/ae350_rv32_xip_defconfig +++ b/configs/ae350_rv32_xip_defconfig @@ -23,6 +23,7 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -49,3 +50,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y \ No newline at end of file diff --git a/configs/ae350_rv64_defconfig b/configs/ae350_rv64_defconfig index a4b9ad6162..4aa0b1a29d 100644 --- a/configs/ae350_rv64_defconfig +++ b/configs/ae350_rv64_defconfig @@ -22,6 +22,7 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -48,3 +49,6 @@ CONFIG_BAUDRATE=38400 CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y \ No newline at end of file diff --git a/configs/ae350_rv64_spl_defconfig b/configs/ae350_rv64_spl_defconfig index 834a0fbbdd..1a3c294b16 100644 --- a/configs/ae350_rv64_spl_defconfig +++ b/configs/ae350_rv64_spl_defconfig @@ -32,6 +32,7 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -57,3 +58,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_spl_xip_defconfig b/configs/ae350_rv64_spl_xip_defconfig index b52b8d78d7..f8db0a1a85 100644 --- a/configs/ae350_rv64_spl_xip_defconfig +++ b/configs/ae350_rv64_spl_xip_defconfig @@ -33,6 +33,7 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_IMLS=y CONFIG_CMD_MMC=y CONFIG_CMD_SF_TEST=y +CONFIG_CMD_WDT=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y @@ -58,3 +59,6 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_ATCSPI200_SPI=y # CONFIG_BINMAN_FDT is not set +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_ATCWDT200=y diff --git a/configs/ae350_rv64_xip_defconfig b/configs/ae350_rv64_xip_defconfig index cc5e751c9b..70119f154a 100644 --- a/configs/ae350_rv64_xip_defconfig +++ b/configs/ae350_rv64_xip_defconfig @@ -23,6 +23,7 @@
[PATCH RESEND 1/2] drivers: watchdog: add andes atcwdt200 support
This patch adds an implementation of the Andes watchdog ATCWDT200 driver.
Signed-off-by: CL Wang
Signed-off-by: Randolph
---
drivers/watchdog/Kconfig | 6 +
drivers/watchdog/Makefile| 1 +
drivers/watchdog/atcwdt200_wdt.c | 219 +++
3 files changed, 226 insertions(+)
create mode 100644 drivers/watchdog/atcwdt200_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 07fc4940e9..6b0f77dd3f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -130,6 +130,12 @@ config WDT_AT91
Select this to enable Microchip watchdog timer, which can be found on
some AT91 devices.
+config WDT_ATCWDT200
+ bool "Andes watchdog timer support"
+ depends on WDT
+ help
+ Select this to enable Andes ATCWDT200 watchdog timer
+
config WDT_BCM6345
bool "BCM6345 watchdog timer support"
depends on WDT && (ARCH_BMIPS || BCM6856 || \
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index eef786f5e7..1750ebbb1f 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_WDT_ARM_SMC) += arm_smc_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
+obj-$(CONFIG_WDT_ATCWDT200) += atcwdt200_wdt.o
obj-$(CONFIG_WDT_BCM2835) += bcm2835_wdt.o
obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
obj-$(CONFIG_WDT_BOOKE) += booke_wdt.o
diff --git a/drivers/watchdog/atcwdt200_wdt.c b/drivers/watchdog/atcwdt200_wdt.c
new file mode 100644
index 00..dc34013473
--- /dev/null
+++ b/drivers/watchdog/atcwdt200_wdt.c
@@ -0,0 +1,219 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Andes Technology Corporation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define NODE_NOT_FOUND 0x
+
+#define WDT_WP_MAGIC 0x5aa5
+#define WDT_RESTART_MAGIC 0xcafe
+
+/* Control Register */
+#define REG_WDT_ID 0x00
+#define REG_WDT_CFG0x10
+#define REG_WDT_RS 0x14
+#define REG_WDT_WE 0x18
+#define REG_WDT_STA0x1C
+
+#define RST_TIME_OFF 8
+#define RST_TIME_MSK (0x7 << RST_TIME_OFF)
+#define RST_CLK_128(0 << RST_TIME_OFF)
+#define RST_CLK_256(1 << RST_TIME_OFF)
+#define RST_CLK_512(2 << RST_TIME_OFF)
+#define RST_CLK_1024 (3 << RST_TIME_OFF)
+#define INT_TIME_OFF 4
+#define INT_TIME_MSK (0xf << INT_TIME_OFF)
+#define INT_CLK_2_6(0 << INT_TIME_OFF) /* clk period*2^6 */
+#define INT_CLK_2_8(1 << INT_TIME_OFF) /* clk period*2^8 */
+#define INT_CLK_2_10 (2 << INT_TIME_OFF) /* clk period*2^10 */
+#define INT_CLK_2_11 (3 << INT_TIME_OFF) /* clk period*2^11 */
+#define INT_CLK_2_12 (4 << INT_TIME_OFF) /* clk period*2^12 */
+#define INT_CLK_2_13 (5 << INT_TIME_OFF) /* clk period*2^13 */
+#define INT_CLK_2_14 (6 << INT_TIME_OFF) /* clk period*2^14 */
+#define INT_CLK_2_15 (7 << INT_TIME_OFF) /* clk period*2^15 */
+#define INT_CLK_2_17 (8 << INT_TIME_OFF) /* clk period*2^17 */
+#define INT_CLK_2_19 (9 << INT_TIME_OFF) /* clk period*2^19 */
+#define INT_CLK_2_21 (10 << INT_TIME_OFF) /* clk period*2^21 */
+#define INT_CLK_2_23 (11 << INT_TIME_OFF) /* clk period*2^23 */
+#define INT_CLK_2_25 (12 << INT_TIME_OFF) /* clk period*2^25 */
+#define INT_CLK_2_27 (13 << INT_TIME_OFF) /* clk period*2^27 */
+#define INT_CLK_2_29 (14 << INT_TIME_OFF) /* clk period*2^29 */
+#define INT_CLK_2_31 (15 << INT_TIME_OFF) /* clk period*2^31 */
+#define INT_CLK_MIN0x0
+#define INT_CLK_MAX_16B0x7
+#define INT_CLK_MAX_32B0xF
+#define RST_EN BIT(3)
+#define INT_EN BIT(2)
+#define CLK_PCLK BIT(1)
+#define WDT_EN BIT(0)
+#define INT_EXPIREDBIT(0)
+
+#define INT_TIME_ARRAY 16
+#define RST_TIME_ARRAY 8
+
+struct wdt_priv {
+ void __iomem *base;
+ u32 wdt_clk_src;
+ u32 clk_freq;
+ u8 max_clk;
+};
+
+static inline u8 atcwdt_get_2_power_of_n(u8 index, u8 type)
+{
+ u8 div_int[INT_TIME_ARRAY] = {6, 8, 10, 11, 12, 13, 14, 15, 17, 19, 21,
23, 25, 27, 29, 31};
+ u8 div_rst[RST_TIME_ARRAY] = {7, 8, 9, 10, 11, 12, 13, 14};
+ u8 *pdiv;
+
+ if (type == RST_TIME_ARRAY)
+ pdiv = div_rst;
+ else
+ pdiv = div_int;
+
+ if (index >= type)
+ index = type - 1;
+
+ return pdiv[index];
+}
+
+static u8 atwdt_search_msb(u64 freq_ms, u8 type)
+{
+ u64 result;
+ u64 freq_sec;
+ u8 index;
+
+ freq_sec = freq_ms / 1000;
+ for (index = 0; index < type; index++) {
+ result = freq_sec >> atcwdt_get_2_power_of_n(index, type);
+
+ if (result <= 1)
+ break;
+ }
+
+ return index;
+}
+
+static int
Re: [PATHv11 07/43] net/lwip: implement wget cmd
Hi Maxim, On Mon, Nov 27, 2023 at 5:46 PM Maxim Uvarov wrote: > > U-Boot recently got support for an alternative network stack using LWIP. > Replace wget command with the LWIP variant while keeping the output and > error messages identical. > > Signed-off-by: Maxim Uvarov Do you know whether this wget issue also happens when LWIP is used? https://lore.kernel.org/u-boot/caj+vnu2u9w2nrt6hf1caeq_56sdqviuezudd1iyopdf1cna...@mail.gmail.com/
Re: [PATHv11 15/43] test_efi_loader.py: use $filesize var
On 27/11/2023 19:18, Tom Rini wrote:
On Mon, Nov 27, 2023 at 06:56:58PM +0600, Maxim Uvarov wrote:
bootefi code relays in internal variable then to filesize environment.
lwip tftp do not update this variable. For not I update test to provide
correct size.
Signed-off-by: Maxim Uvarov
This is a lwip problem then, loading a "file" should update filesize and
there's use cases, not just tests, which rely on this behavior.
filesize is updated in tftp_close, but what's missing is a call to
efi_set_bootdev
when tftp transfer is finished:
https://elixir.bootlin.com/u-boot/latest/source/net/tftp.c#L305 :
if (IS_ENABLED(CONFIG_CMD_BOOTEFI)) {
if (!tftp_put_active)
efi_set_bootdev("Net", "", tftp_filename,
map_sysmem(tftp_load_addr, 0),
net_boot_file_size);
Neil
[PATCH] nand: Add a watch command
This is a debug command to monitor the retention state of the data on the array. The command needs a duplication of the mtd_read_oob() function to actually return the maximum number of bitflips encountered while reading the page. We could write a specific implementation for the Sunxi driver but this is probably enough. nand watch - check an area for bitflips nand watch.part - check a partition for bitflips nand watch.chip - check the whole device for bitflips The output may be a bit verbose and could look like: => nand watch.chip device 0 whole chip size adjusted to 0xff6 (5 bad blocks) NAND watch for bitflips in area 0x0-0xff6: Page 0 (0x) -> error -74 Page 1 (0x0800) -> error -74 Page 2 (0x1000) -> error -74 Page 3 (0x1800) -> error -74 Page 4 (0x2000) -> error -74 Page 5 (0x2800) -> error -74 Page 6 (0x3000) -> error -74 Page 7 (0x3800) -> error -74 Page 8 (0x4000) -> error -74 Page 9 (0x4800) -> error -74 Page 10 (0x5000) -> error -74 Page 11 (0x5800) -> error -74 Page 12 (0x6000) -> error -74 Page 13 (0x6800) -> error -74 Page 14 (0x7000) -> error -74 Page 15 (0x7800) -> error -74 Page 16 (0x8000) -> error -74 Page 17 (0x8800) -> error -74 Page 18 (0x9000) -> error -74 Page 19 (0x9800) -> error -74 Page 20 (0xa000) -> error -74 Page 21 (0xa800) -> error -74 Page 22 (0xb000) -> error -74 Page 23 (0xb800) -> error -74 Page1110 (0x0022b000) -> up to 1 bf/chunk Page1122 (0x00231000) -> up to 1 bf/chunk Page1132 (0x00236000) -> up to 1 bf/chunk Page1362 (0x002a9000) -> up to 1 bf/chunk Page4990 (0x009bf000) -> up to 1 bf/chunk Page5728 (0x00b3) -> up to 1 bf/chunk Page7116 (0x00de6000) -> up to 1 bf/chunk Page7160 (0x00dfc000) -> up to 1 bf/chunk Page7494 (0x00ea3000) -> up to 1 bf/chunk Page 10842 (0x0152d000) -> up to 1 bf/chunk Page 11614 (0x016af000) -> up to 1 bf/chunk Page 11970 (0x01761000) -> up to 1 bf/chunk Page 12536 (0x0187c000) -> up to 1 bf/chunk Page 12687 (0x018c7800) -> up to 1 bf/chunk Page 14298 (0x01bed000) -> up to 1 bf/chunk Page 18268 (0x023ae000) -> up to 1 bf/chunk Page 18760 (0x024a4000) -> up to 1 bf/chunk Page 21440 (0x029e) -> up to 1 bf/chunk Page 22336 (0x02ba) -> up to 1 bf/chunk Page 22592 (0x02c2) -> up to 1 bf/chunk Page 23872 (0x02ea) -> up to 1 bf/chunk Page 27584 (0x035e) -> up to 1 bf/chunk Page 35008 (0x0446) -> up to 1 bf/chunk Page 37184 (0x048a) -> up to 1 bf/chunk Page 41728 (0x0518) -> up to 1 bf/chunk Page 42176 (0x0526) -> up to 1 bf/chunk Page 43200 (0x0546) -> up to 1 bf/chunk Page 43328 (0x054a) -> up to 1 bf/chunk Page 45376 (0x058a) -> up to 1 bf/chunk Page 47040 (0x05be) -> up to 1 bf/chunk Page 47552 (0x05ce) -> up to 1 bf/chunk Page 49344 (0x0606) -> up to 1 bf/chunk Page 49856 (0x0616) -> up to 1 bf/chunk Page 62784 (0x07aa) -> up to 1 bf/chunk Page 65153 (0x07f40800) -> up to 1 bf/chunk Page 65228 (0x07f66000) -> up to 1 bf/chunk Page 65382 (0x07fb3000) -> up to 1 bf/chunk Page 98624 (0x0c0a) -> up to 1 bf/chunk Page 101952 (0x0c72) -> up to 1 bf/chunk Page 107584 (0x0d22) -> up to 1 bf/chunk Page 118208 (0x0e6e) -> up to 1 bf/chunk Page 126656 (0x0f76) -> up to 1 bf/chunk Page 127680 (0x0f96) -> up to 1 bf/chunk Page 129920 (0x0fdc) -> up to 1 bf/chunk Maximum number of bitflips: 1 Pages with bitflips: 44/130752 It is also possible to reduce the output with the .quiet suffix in order to just show the summary. => nand watch.chip device 0 whole chip size adjusted to 0xff6 (5 bad blocks) NAND watch for bitflips in area 0x0-0xff6: Maximum number of bitflips: 1 Pages with bitflips: 44/130752 Signed-off-by: Miquel Raynal --- Hello, I recently came across a batch of NANDs with a lot of "natural" bitflips so in order to easily and objectively characterize how unstable these parts were, I wrote this little tool which was pretty handy to have in U-Boot. I believe it can be useful for others as well, so here is the patch. Cheers, Miquèl cmd/Kconfig | 5 ++ cmd/nand.c | 103 drivers/mtd/mtdcore.c | 22 + include/linux/mtd/mtd.h | 1 + 4 files changed, 131 insertions(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 451baa3ecac..0524328d373 100644 ---
Re: [PATHv11 00/43] net/lwip: add lwip library for the network stack
Hi, On 27/11/2023 13:56, Maxim Uvarov wrote: Hello, Please find updated version of lwip patches. Changes are in the changelog bellow. I've ran it on the libretech-cc board, and tried to load grub over tftp, and I got this strange EFI boot error: U-Boot 2024.01-rc3-00056-g10d85cb3e3 (Nov 28 2023 - 11:17:24 +0100) libretech-cc Model: Libre Computer AML-S905X-CC SoC: Amlogic Meson GXL (S905X) Revision 21:d (84:2) DRAM: 2 GiB Net: eth0: ethernet@c941 Hit any key to stop autoboot: 0 => setenv autoload no => dhcp ethernet@c941 LPA corruption - aneg restart ethernet@c941 Waiting for PHY auto negotiation to complete done Speed: 100, full duplex eth0: ethernet@c941 3e:a6:23:c0:39:4b active dhcp_tmo 20/20 dhcp_tmo 19/20 DHCP client bound to address 10.34.56.105 => tftpboot 808 grubaa64.efi init already done for ethernet@c941 Speed: 100, full duplex TFTP from server 10.34.56.1; our IP address is 10.34.56.105 Filename 'grubaa64.efi'. Load address: 0x808 Loading: done Bytes transferred = 4288512 (0x417000 hex) => crc32 808 0x417000 crc32 for 0808 ... 08496fff ==> c79bc066 - DHCP OK, - transfer OK - CRC32 value OK but then trying to run the EFI binary: => bootefi 808 No EFI system partition No EFI system partition Failed to persist EFI variables No UEFI binary known at 808 This is what I get on the current master without this patchset: U-Boot 2024.01-rc3-00013-gacae7eb5fe (Nov 28 2023 - 11:29:38 +0100) libretech-cc Model: Libre Computer AML-S905X-CC SoC: Amlogic Meson GXL (S905X) Revision 21:d (84:2) DRAM: 2 GiB Net: eth0: ethernet@c941 Hit any key to stop autoboot: 0 => setenv autoload no => dhcp ethernet@c941 LPA corruption - aneg restart ethernet@c941 Waiting for PHY auto negotiation to complete done Speed: 100, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.34.56.105 (1008 ms) => tftpboot 808 grubaa64.efi Speed: 100, full duplex Using ethernet@c941 device TFTP from server 10.34.56.1; our IP address is 10.34.56.105 Filename 'grubaa64.efi'. Load address: 0x808 Loading: ##T #T T ## # # # # # # # # # # # ## 199.2 KiB/s done Bytes transferred = 4288512 (417000 hex) => crc32 808 0x417000 crc32 for 0808 ... 08496fff ==> c79bc066 => bootefi 808 No EFI system partition No EFI system partition Failed to persist EFI variables Booting /grubaa64.efi Welcome to GRUB! grub> net_ls_addr efinet0 3e:a6:23:c0:39:4b 10.34.56.105 I don't see what's wrong, crc32 is good and env variables are the same: fileaddr=808 filesize=417000 Neil Thank you, Maxim. changelog: v11: - v11 is mosly respin of v10 patches with CI error fixes. Gitlab CI: https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/18368 Azure CI: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=7366=results (Azure CI, which is connected to github. Sometime I can see tftp timeout after some part of download there, but that can not be reproduced locally. While Gitblab CI is stable. Because of num tries in CI I suspect this CI was not always reliable.) Azure and Gitlab also have different toolchains and I would say Gitlab generates bigger code then Azure CI. Also many boards have a binary limit size of 800k (even
[PATCH v3 3/3] board: Add support for Conclusive WHLE-LS1088A
Introduce support for Conclusive WHLE-LS1088A Single Board Computer.
Co-developed-by: Jakub Klama
Signed-off-by: Jakub Klama
Signed-off-by: Artur Rojek
---
v3: new patch
arch/arm/Kconfig | 19 ++
arch/arm/dts/Makefile | 1 +
arch/arm/dts/fsl-ls1088a-whle-u-boot.dtsi | 8 +
arch/arm/dts/fsl-ls1088a-whle.dts | 235 ++
board/conclusive/whle-ls1088a/Kconfig | 29 ++
board/conclusive/whle-ls1088a/MAINTAINERS | 11 +
board/conclusive/whle-ls1088a/Makefile| 7 +
board/conclusive/whle-ls1088a/ddr.c | 134
board/conclusive/whle-ls1088a/ddr.h | 47 +++
board/conclusive/whle-ls1088a/eth.c | 13 +
board/conclusive/whle-ls1088a/whle-ls1088a.c | 301 ++
.../conclusive/whle-ls1088a/whle-ls1088a.env | 13 +
configs/whle_ls1088a_emmc_defconfig | 84 +
configs/whle_ls1088a_qspi_defconfig | 84 +
include/configs/whle_ls1088a.h| 92 ++
15 files changed, 1078 insertions(+)
create mode 100644 arch/arm/dts/fsl-ls1088a-whle-u-boot.dtsi
create mode 100644 arch/arm/dts/fsl-ls1088a-whle.dts
create mode 100644 board/conclusive/whle-ls1088a/Kconfig
create mode 100644 board/conclusive/whle-ls1088a/MAINTAINERS
create mode 100644 board/conclusive/whle-ls1088a/Makefile
create mode 100644 board/conclusive/whle-ls1088a/ddr.c
create mode 100644 board/conclusive/whle-ls1088a/ddr.h
create mode 100644 board/conclusive/whle-ls1088a/eth.c
create mode 100644 board/conclusive/whle-ls1088a/whle-ls1088a.c
create mode 100644 board/conclusive/whle-ls1088a/whle-ls1088a.env
create mode 100644 configs/whle_ls1088a_emmc_defconfig
create mode 100644 configs/whle_ls1088a_qspi_defconfig
create mode 100644 include/configs/whle_ls1088a.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 609571e6e421..cd53fcaac883 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1869,6 +1869,24 @@ config TARGET_WHLE_LS1046A
Layerscape Architecture processor:
https://conclusive.tech/products/whle-ls1-sbc/
+config TARGET_WHLE_LS1088A
+ bool "Support Conclusive WHLE-LS1088A"
+ select ARCH_LS1088A
+ select ARM64
+ select ARMV8_MULTIENTRY
+ select ARCH_SUPPORT_TFABOOT
+ select BOARD_EARLY_INIT_F
+ select BOARD_LATE_INIT
+ select GPIO_EXTRA_HEADER
+ select DM_SPI_FLASH if DM_SPI
+ imply SCSI
+ help
+ Support for Conclusive WHLE-LS1088A platform.
+ The WHLE-LS1088A is a high-performance Single Board Computer with
+ extensive connectivity features that supports the QorIQ LS1088A
+ Layerscape Architecture processor:
+ https://conclusive.tech/products/whle-ls1-sbc/
+
config TARGET_TEN64
bool "Support ten64"
select ARCH_LS1088A
@@ -2318,6 +2336,7 @@ source "board/broadcom/bcmns/Kconfig"
source "board/broadcom/bcmns3/Kconfig"
source "board/cavium/thunderx/Kconfig"
source "board/conclusive/whle-ls1046a/Kconfig"
+source "board/conclusive/whle-ls1088a/Kconfig"
source "board/eets/pdu001/Kconfig"
source "board/emulation/qemu-arm/Kconfig"
source "board/freescale/ls2080aqds/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8dcbf29df363..b0782b4f29bc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -591,6 +591,7 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls1088a-qds.dtb \
fsl-ls1088a-qds-21-x.dtb \
fsl-ls1088a-qds-29-x.dtb \
+ fsl-ls1088a-whle.dtb \
fsl-ls1028a-rdb.dtb \
fsl-ls1028a-qds-duart.dtb \
fsl-ls1028a-qds-lpuart.dtb \
diff --git a/arch/arm/dts/fsl-ls1088a-whle-u-boot.dtsi
b/arch/arm/dts/fsl-ls1088a-whle-u-boot.dtsi
new file mode 100644
index ..bbe93a1d6e4f
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-whle-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2020-2023 Conclusive Engineering Sp. z o. o.
+ */
+
+#include
+
+#include "fsl-ls1088a-u-boot.dtsi"
diff --git a/arch/arm/dts/fsl-ls1088a-whle.dts
b/arch/arm/dts/fsl-ls1088a-whle.dts
new file mode 100644
index ..76ef1c748059
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-whle.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2020-2023 Conclusive Engineering Sp. z o. o.
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1088a.dtsi"
+
+/ {
+ model = "Conclusive WHLE-LS1088A";
+ compatible = "conclusive,whle-ls1088a", "fsl,ls1088a";
+
+ chosen {
+ stdout-path =
+ };
+
+ aliases {
+ spi0 =
+ };
+};
+
+ {
+ status = "okay";
+ phy-connection-type = "10gbase-r";
+};
+
+ {
+ status = "okay";
+ phy-connection-type = "10gbase-r";
+};
+
+ {
+ status = "okay";
+ phy-handle = <_phy3>;
+ phy-connection-type = "sgmii";
+};
+
+ {
+ status = "okay";
+
[PATCH v3 2/3] board: Add support for Conclusive WHLE-LS1046A
Introduce support for Conclusive WHLE-LS1046A Single Board Computer.
Co-developed-by: Jakub Klama
Signed-off-by: Jakub Klama
Signed-off-by: Artur Rojek
---
v3: no change
v2: - drop non-DM_ETH case
- clean-up defines in configs/whle_ls1046a.h: remove unneeded ones,
move others to appropriate files in board directory
- move environment variables to whle-ls1046a.env
- move away from distro_bootcmd and use BOOTSTD
- fix i2c-mux node parent and ext_i2c address in Device Tree
- style changes to eth.c
- fix CONFIG_MTDPARTS_DEFAULT value in defconfigs
arch/arm/Kconfig | 19 ++
arch/arm/dts/Makefile | 1 +
arch/arm/dts/fsl-ls1046a-whle.dts | 208 +
board/conclusive/whle-ls1046a/Kconfig | 15 ++
board/conclusive/whle-ls1046a/MAINTAINERS | 9 +
board/conclusive/whle-ls1046a/Makefile| 7 +
board/conclusive/whle-ls1046a/ddr.c | 21 ++
board/conclusive/whle-ls1046a/eth.c | 65 ++
board/conclusive/whle-ls1046a/whle-ls1046a.c | 215 ++
.../conclusive/whle-ls1046a/whle-ls1046a.env | 13 ++
configs/whle_ls1046a_emmc_defconfig | 83 +++
configs/whle_ls1046a_qspi_defconfig | 84 +++
include/configs/whle_ls1046a.h| 47
13 files changed, 787 insertions(+)
create mode 100644 arch/arm/dts/fsl-ls1046a-whle.dts
create mode 100644 board/conclusive/whle-ls1046a/Kconfig
create mode 100644 board/conclusive/whle-ls1046a/MAINTAINERS
create mode 100644 board/conclusive/whle-ls1046a/Makefile
create mode 100644 board/conclusive/whle-ls1046a/ddr.c
create mode 100644 board/conclusive/whle-ls1046a/eth.c
create mode 100644 board/conclusive/whle-ls1046a/whle-ls1046a.c
create mode 100644 board/conclusive/whle-ls1046a/whle-ls1046a.env
create mode 100644 configs/whle_ls1046a_emmc_defconfig
create mode 100644 configs/whle_ls1046a_qspi_defconfig
create mode 100644 include/configs/whle_ls1046a.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d812685c9842..609571e6e421 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1851,6 +1851,24 @@ config TARGET_SL28
help
Support for Kontron SMARC-sAL28 board.
+config TARGET_WHLE_LS1046A
+ bool "Support Conclusive WHLE-LS1046A"
+ select ARCH_LS1046A
+ select ARM64
+ select ARMV8_MULTIENTRY
+ select ARCH_SUPPORT_TFABOOT
+ select BOARD_EARLY_INIT_F
+ select BOARD_LATE_INIT
+ select GPIO_EXTRA_HEADER
+ select DM_SPI_FLASH if DM_SPI
+ imply SCSI
+ help
+ Support for Conclusive WHLE-LS1046A platform.
+ The WHLE-LS1046A is a high-performance Single Board Computer with
+ extensive connectivity features that supports the QorIQ LS1046A
+ Layerscape Architecture processor:
+ https://conclusive.tech/products/whle-ls1-sbc/
+
config TARGET_TEN64
bool "Support ten64"
select ARCH_LS1088A
@@ -2299,6 +2317,7 @@ source "board/cortina/presidio-asic/Kconfig"
source "board/broadcom/bcmns/Kconfig"
source "board/broadcom/bcmns3/Kconfig"
source "board/cavium/thunderx/Kconfig"
+source "board/conclusive/whle-ls1046a/Kconfig"
source "board/eets/pdu001/Kconfig"
source "board/emulation/qemu-arm/Kconfig"
source "board/freescale/ls2080aqds/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1be08c5fdc2e..8dcbf29df363 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -615,6 +615,7 @@ dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1046a-qds-lpuart.dtb \
fsl-ls1046a-rdb.dtb \
fsl-ls1046a-frwy.dtb \
+ fsl-ls1046a-whle.dtb \
fsl-ls1012a-qds.dtb \
fsl-ls1012a-rdb.dtb \
fsl-ls1012a-2g5rdb.dtb \
diff --git a/arch/arm/dts/fsl-ls1046a-whle.dts
b/arch/arm/dts/fsl-ls1046a-whle.dts
new file mode 100644
index ..1aed3e8c4701
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1046a-whle.dts
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2020-2023 Conclusive Engineering Sp. z o. o.
+ */
+
+#include
+
+/dts-v1/;
+#include "fsl-ls1046a.dtsi"
+
+/ {
+ model = "Conclusive WHLE-LS1046A";
+ compatible = "conclusive,whle-ls1046a", "fsl,ls1046a";
+
+ chosen {
+ stdout-path =
+ };
+
+ aliases {
+ spi0 =
+ };
+};
+
+ {
+ pcie@340 {
+ status = "okay";
+ };
+};
+
+ {
+ status = "okay";
+
+ gd25lq128: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <5000>;
+ reg = <0>;
+
+ partitions {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fixed-partitions";
+
+ partition@0 {
[PATCH v3 1/3] armv8: layerscape: Enable ext4 environment storage
From: Jakub Klama Some boards keep their environment on MMC storage within an ext4 partition. Signed-off-by: Jakub Klama Signed-off-by: Artur Rojek Reviewed-by: Tom Rini --- v2-v3: no change arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index 12d31184ad91..3775cb493732 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c @@ -857,6 +857,11 @@ enum env_location arch_env_get_location(enum env_operation op, int prio) break; } +#ifdef CONFIG_ENV_IS_IN_EXT4 + if (env_loc == ENVL_MMC) + return ENVL_EXT4; +#endif + return env_loc; } #endif /* CONFIG_TFABOOT */ -- 2.43.0
[PATCH v3 0/3] Conclusive WHLE-LS1 support (was: Conclusive WHLE-LS1046A support)
Hi all, this is v3 of the WHLE-LS1 support. The major change in this version is addition of WHLE-LS1088A board support, next to the WHLE-LS1046A found in previous iterations of this series. Patch [1/3] and [2/3] remain unchanged. Patch [3/3] introduces WHLE-LS1088A board support. Artur Rojek (2): board: Add support for Conclusive WHLE-LS1046A board: Add support for Conclusive WHLE-LS1088A Jakub Klama (1): armv8: layerscape: Enable ext4 environment storage arch/arm/Kconfig | 38 +++ arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 5 + arch/arm/dts/Makefile | 2 + arch/arm/dts/fsl-ls1046a-whle.dts | 208 arch/arm/dts/fsl-ls1088a-whle-u-boot.dtsi | 8 + arch/arm/dts/fsl-ls1088a-whle.dts | 235 ++ board/conclusive/whle-ls1046a/Kconfig | 15 + board/conclusive/whle-ls1046a/MAINTAINERS | 9 + board/conclusive/whle-ls1046a/Makefile| 7 + board/conclusive/whle-ls1046a/ddr.c | 21 ++ board/conclusive/whle-ls1046a/eth.c | 65 board/conclusive/whle-ls1046a/whle-ls1046a.c | 215 + .../conclusive/whle-ls1046a/whle-ls1046a.env | 13 + board/conclusive/whle-ls1088a/Kconfig | 29 ++ board/conclusive/whle-ls1088a/MAINTAINERS | 11 + board/conclusive/whle-ls1088a/Makefile| 7 + board/conclusive/whle-ls1088a/ddr.c | 134 board/conclusive/whle-ls1088a/ddr.h | 47 +++ board/conclusive/whle-ls1088a/eth.c | 13 + board/conclusive/whle-ls1088a/whle-ls1088a.c | 301 ++ .../conclusive/whle-ls1088a/whle-ls1088a.env | 13 + configs/whle_ls1046a_emmc_defconfig | 83 + configs/whle_ls1046a_qspi_defconfig | 84 + configs/whle_ls1088a_emmc_defconfig | 84 + configs/whle_ls1088a_qspi_defconfig | 84 + include/configs/whle_ls1046a.h| 47 +++ include/configs/whle_ls1088a.h| 92 ++ 27 files changed, 1870 insertions(+) create mode 100644 arch/arm/dts/fsl-ls1046a-whle.dts create mode 100644 arch/arm/dts/fsl-ls1088a-whle-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1088a-whle.dts create mode 100644 board/conclusive/whle-ls1046a/Kconfig create mode 100644 board/conclusive/whle-ls1046a/MAINTAINERS create mode 100644 board/conclusive/whle-ls1046a/Makefile create mode 100644 board/conclusive/whle-ls1046a/ddr.c create mode 100644 board/conclusive/whle-ls1046a/eth.c create mode 100644 board/conclusive/whle-ls1046a/whle-ls1046a.c create mode 100644 board/conclusive/whle-ls1046a/whle-ls1046a.env create mode 100644 board/conclusive/whle-ls1088a/Kconfig create mode 100644 board/conclusive/whle-ls1088a/MAINTAINERS create mode 100644 board/conclusive/whle-ls1088a/Makefile create mode 100644 board/conclusive/whle-ls1088a/ddr.c create mode 100644 board/conclusive/whle-ls1088a/ddr.h create mode 100644 board/conclusive/whle-ls1088a/eth.c create mode 100644 board/conclusive/whle-ls1088a/whle-ls1088a.c create mode 100644 board/conclusive/whle-ls1088a/whle-ls1088a.env create mode 100644 configs/whle_ls1046a_emmc_defconfig create mode 100644 configs/whle_ls1046a_qspi_defconfig create mode 100644 configs/whle_ls1088a_emmc_defconfig create mode 100644 configs/whle_ls1088a_qspi_defconfig create mode 100644 include/configs/whle_ls1046a.h create mode 100644 include/configs/whle_ls1088a.h -- 2.43.0
Re: [PATCH v2 1/3] arm: mvebu: Espressobin: move FDT fixup into a separate function
On Fri, Oct 20, 2023 at 12:21 PM Robert Marko wrote:
>
> Currently, Esspresobin FDT is being fixed up directly in ft_board_setup()
> which makes it hard to add support for any other board to be fixed up.
>
> So, lets just move the FDT fixup code to a separate function and call it
> if compatible matches, there should be no functional change.
>
> Signed-off-by: Robert Marko
> Reviewed-by: Stefan Roese
Hi Stefan,
Is there anything I can do to get this series merged?
Regards,
Robert
> ---
> board/Marvell/mvebu_armada-37xx/board.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/board/Marvell/mvebu_armada-37xx/board.c
> b/board/Marvell/mvebu_armada-37xx/board.c
> index 04124d8014..1471caa9a6 100644
> --- a/board/Marvell/mvebu_armada-37xx/board.c
> +++ b/board/Marvell/mvebu_armada-37xx/board.c
> @@ -363,18 +363,14 @@ EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, last_stage_init);
> #endif
>
> #ifdef CONFIG_OF_BOARD_SETUP
> -int ft_board_setup(void *blob, struct bd_info *bd)
> +static int espressobin_fdt_setup(void *blob)
> {
> -#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> int ret;
> int spi_off;
> int parts_off;
> int part_off;
>
> /* Fill SPI MTD partitions for Linux kernel on Espressobin */
> - if (!of_machine_is_compatible("globalscale,espressobin"))
> - return 0;
> -
> spi_off = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
> if (spi_off < 0)
> return 0;
> @@ -459,6 +455,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> return 0;
> }
>
> + return 0;
> +}
> +
> +int ft_board_setup(void *blob, struct bd_info *bd)
> +{
> +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> + if (of_machine_is_compatible("globalscale,espressobin"))
> + return espressobin_fdt_setup(blob);
> #endif
> return 0;
> }
> --
> 2.41.0
>
--
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
1 Zagreb, Croatia
Email: robert.ma...@sartura.hr
Web: www.sartura.hr
Re: [PATHv11 33/43] configs/am335x_evm_defconfig: inc SPL size
On Mon, 27 Nov 2023 at 22:31, Tom Rini wrote: > On Mon, Nov 27, 2023 at 03:52:50PM +, Peter Robinson wrote: > > On Mon, Nov 27, 2023 at 3:32 PM Maxim Uvarov > wrote: > > > > > > > > > > > > On Mon, 27 Nov 2023 at 20:08, Tom Rini wrote: > > >> > > >> On Mon, Nov 27, 2023 at 08:06:23PM +0600, Maxim Uvarov wrote: > > >> > On Mon, 27 Nov 2023 at 19:08, Tom Rini wrote: > > >> > > > >> > > On Mon, Nov 27, 2023 at 06:57:16PM +0600, Maxim Uvarov wrote: > > >> > > > > >> > > > Increase allowed binary size to fit lwip code. > > >> > > > > > >> > > > Signed-off-by: Maxim Uvarov > > >> > > > --- > > >> > > > configs/am335x_evm_defconfig | 1 + > > >> > > > 1 file changed, 1 insertion(+) > > >> > > > > > >> > > > diff --git a/configs/am335x_evm_defconfig > b/configs/am335x_evm_defconfig > > >> > > > index f048e60f7f..9fd608bd76 100644 > > >> > > > --- a/configs/am335x_evm_defconfig > > >> > > > +++ b/configs/am335x_evm_defconfig > > >> > > > @@ -124,3 +124,4 @@ CONFIG_WDT=y > > >> > > > CONFIG_DYNAMIC_CRC_TABLE=y > > >> > > > CONFIG_RSA=y > > >> > > > CONFIG_LZO=y > > >> > > > +CONFIG_SPL_MAX_SIZE=0x29000 > > >> > > > > >> > > As probably a problem for other platforms you made this change on > too, > > >> > > you can't do this. The link limit is here because that's the > limit the > > >> > > hardware (and ROM) imposes. > > >> > > > > >> > > You might need to either: > > >> > > - Figure out how to make lwip even tinier for the SPL case > > >> > > - Limit the old network stack to just for SPL, and a later task > is to > > >> > > reduce what's in the old stack to just what's also needed > within SPL. > > >> > > > > >> > > > > >> > Thanks Tom. All these size changes need to be reviewed. Some of > them are > > >> > ok, I think like for x86 or qemu virt, but some of them might not > work. > > >> > > > >> > Question - Do we need networking inside SPL rather than in the main > binary? > > >> > Is it a real use case? > > >> > > >> Yes, the device supports loading SPL, and then SPL loading U-Boot both > > >> over USB RNDIS as well as regular physical ethernet. > > >> > > >> -- > > >> Tom > > > > > > > > > That looks like not a production use case. USB + NET + drivers + EXT4 > + NAND + MTD and everything else and trying to fit into SPL. > > > With enabling LTO I still need 4k (without dropping current code). > From one point it's too synthetic use case here and might be a historical > > > limitation which we will not see on future boards. From the other > point it will be good to not break it somehow > > > > Does this still include the old network code? > > > > Also I wonder if we can have a paired down SPL_LWIP option that > > removes things like PXE and HTTP/wget because none of those would be > > used in the SPL use case as they're all brand new. > > To be clear, I am fine with either "old network stack only for SPL" or > "figure out how to pair down lwip to just SPL features". In fact having > said that, the first thing I would suggest is to turn off LTO as it > makes reading the linker map file harder, increase the size limit for > this platform, and take a look at what's being linked in and not > discarded in SPL, for networking, in spl/u-boot-spl.map. Maybe the > answer is that we just need to be more careful about using > IS_ENABLED/CONFIG_IS_ENABLED (and obj-$(CONFIG_$(SPL_)FOO)) in the lwip > series. > > -- > Tom > Yea. If I disable TCP then we get the right size for this board. So for SPL I think to build without TCP so that ping, dhcp and tftp will still work. For normal binary TCP will be enabled. For other boards with limits I think also to disable TCP for now. BR, Maxim.
Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
Hi Simon, On 12:05-20231106, Andrew Davis wrote: > On 11/6/23 11:47 AM, Simon Glass wrote: > > Hi Andrew, > > > > On Mon, 6 Nov 2023 at 10:27, Andrew Davis wrote: > > > > > > On 11/6/23 9:31 AM, Tom Rini wrote: > > > > On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote: > > > > > Hi Simon, > > > > > > > > > > On 11:22-20231005, Simon Glass wrote: > > > > > > Hi Nishanth, > > > > > > > > > > > > On Thu, 5 Oct 2023 at 11:16, Nishanth Menon wrote: > > > > > > > > > > > > > > On 12:10-20231005, Nishanth Menon wrote: > > > > > > > > On 12:36-20231005, Tom Rini wrote: > > > > > > > > > On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote: > > > > > > > > > > On 10/4/23 8:54 AM, Nishanth Menon wrote: > > > > > > > > > > > On 08:48-20231004, Andrew Davis wrote: > > > > > > > > > > > > On 10/4/23 8:23 AM, Roger Quadros wrote: > > > > > > > > > > > > > ti_mmc is not a valid boot_target for standard boot > > > > > > > > > > > > > flow so > > > > > > > > > > > > > > > > > > > > > > > > Is there some way to make it into a valid boot_target? > > > > > > > > > > > > Otherwise > > > > > > > > > > > > how do we use uEnv.txt files, or boot from FIT images > > > > > > > > > > > > with overlays? > > > > > > > > > > > > > > > > > > > > > > envboot takes care of uEnv.txt file (see > > > > > > > > > > > https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/) > > > > > > > > > > > > > > > > > > > > > > Early remote proc loading and FIT image is a question for > > > > > > > > > > > stdboot itself. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If stdboot is missing these features then we shouldn't > > > > > > > > > > switch until it > > > > > > > > > > has them. I'm all for switching to this, but only if it is > > > > > > > > > > complete. > > > > > > > > > > > > > > > > > > Depends on what you mean? Did you mean an option to run > > > > > > > > > scripts > > > > > > > > > (exists) or an option to do what TI needs done, via > > > > > > > > > boot/bootmeth_something.c ? If the latter, someone from TI > > > > > > > > > needs to > > > > > > > > > figure out what that should be and do (but plumbing-wise > > > > > > > > > everything it > > > > > > > > > needs should exist). > > > > > > > > > > > > > > > > Andrew is generalizing here (on the wrong patch though). > > > > > > > > > > > > > > > > On am62x platforms, there is nothing regressing with this > > > > > > > > series. The > > > > > > > > challenge is early remote_proc loading which is done for J7* > > > > > > > > platforms. > > > > > > > > > > > > > > > > How that is initiated as part of bootmethods is something of a > > > > > > > > gap. > > > > > > > > > > > > > > > > The other gap has been support for uEnv.txt -> which we can > > > > > > > > workaround > > > > > > > > at the moment by using CONFIG_BOOTCOMMAND="run envboot; > > > > > > > > bootflow scan > > > > > > > > -lb" in defconfig (This series from Roger already does that - > > > > > > > > hence I am > > > > > > > > saying that Andrew is complaining on the wrong series). > > > > > > > > > > > > > > > > Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan > > > > > > > > -lb" and > > > > > > > > uEnv.txt remoteproc loads and the various standard bootmethods > > > > > > > > should > > > > > > > > "just work". > > > > > > > > > > > > > > > > > > > > > I forgot to add: FIT image authenticated boot flow. That is > > > > > > > really what > > > > > > > ti_mmc distroboot method was trying to solve. > > > > > > > > > > > > > > Maybe Simon or someone know how the stdboot flow handles > > > > > > > authenticated > > > > > > > kernel image and dtb boot flow with FIT image? > > > > > > > > > > > > Yes you can use FIT configuration verification and things should > > > > > > work as normal. > > > > > > > > > > > > > > > > Could you give any reference documentation for this? > > > > > > > > I suspect you should start with doc/usage/fit/beaglebone_vboot.rst > > > > > > > > > > From that doc: > > > > > > ``` > > > Boot the board using the commands below:: > > > > > > setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro > > > rootfstype=ext4 rootwait > > > ext2load mmc 0:2 8200 /boot/image.fit > > > bootm 8200 > > > ``` > > > > > > This is very much not stdboot :( This doc has some good and current info > > > on building > > > a secure FIT image, but much of it is showing its age. Stdboot is still > > > missing > > > > > >* ability to limit boot mode search to only one image (FIT) > > > > What does this mean? Can you please be more specific or give an example? > > > > Sure, for instance with secure boot we only want to search for FIT images > and if for each media this fails we do not want to fall back to other > image types or boot modes (like UART boot or net boot which would bypass > the signature checks). > > Something similar is needed for searching for EFI compatible
Re: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
On 27/11/2023 16:43, Michael Nazzareno Trimarchi wrote:
> Hi dario
>
> On Mon, Nov 27, 2023 at 3:00 PM Leto, Enrico wrote:
>>
>> Hi,
>>
>> Works on my draco thuban AM335x based boards booting from NAND with ECC BCH8
>> code.
>>
>> Tested-by: Enrico Leto
>>
>> Thanks
>>
>>
>>> -Original Message-
>>> From: Michael Nazzareno Trimarchi
>>> Sent: Saturday, November 25, 2023 2:07 PM
>>> To: Roger Quadros
>>> Cc: dario.binac...@amarulasolutions.com; Schocher, Heiko (EXT) (DENX
>>> Software Engineering GmbH) ; Leto, Enrico (SI BP R ZG FW
>>> CCP) ; tr...@konsulko.com; prane...@ti.com;
>>> n...@ti.com; vigne...@ti.com; u-boot@lists.denx.de
>>> Subject: Re: [PATCH] mtd: nand: omap_gpmc: Fix NAND in SPL for AM335x
>>>
>>> Hi Roger
>>>
>>> On Sat, Nov 25, 2023 at 12:16 PM Roger Quadros
>>> wrote:
AM335x uses a special driver "am335x_spl_bch.c" as SPL NAND loader.
This driver expects 1 sector at a time ECC and doesn't work well with
multi-sector ECC that was implemented in commit 04fcd2587321 ("mtd:
rawnand: omap_gpmc: Fix BCH6/16 HW based correction")
Switch back to 1 sector at a time read/ECC.
Fixes: 04fcd2587321 ("mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based
correction")
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_gpmc.c | 95
++--
1 file changed, 29 insertions(+), 66 deletions(-)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
b/drivers/mtd/nand/raw/omap_gpmc.c
index 1a5ed0de31..2d2d2c2b6d 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -293,7 +293,7 @@ static void __maybe_unused
>>> omap_enable_hwecc_bch(struct mtd_info *mtd,
break;
case OMAP_ECC_BCH8_CODE_HW:
bch_type = 1;
- nsectors = chip->ecc.steps;
+ nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH8R_ECC_SIZE0; @@ -306,7 +306,7
@@ static void __maybe_unused omap_enable_hwecc_bch(struct mtd_info
>>> *mtd,
break;
case OMAP_ECC_BCH16_CODE_HW:
bch_type = 0x2;
- nsectors = chip->ecc.steps;
+ nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = 0x01;
ecc_size0 = 52; /* ECC bits in nibbles per
sector */ @@ -345,17 +345,16 @@ static void __maybe_unused
omap_enable_hwecc_bch(struct mtd_info *mtd, }
/**
- * _omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
+ * omap_calculate_ecc_bch - Generate BCH ECC bytes for one sector
* @mtd:MTD device structure
* @dat:The pointer to data on which ecc is computed
* @ecc_code: The ecc_code buffer
- * @sector: The sector number (for a multi sector page)
*
* Support calculating of BCH4/8/16 ECC vectors for one sector
* within a page. Sector number is in @sector.
*/
-static int _omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
- u8 *ecc_code, int sector)
+static int omap_calculate_ecc_bch(struct mtd_info *mtd, const u8 *dat,
+ u8 *ecc_code)
{
struct nand_chip *chip = mtd_to_nand(mtd);
struct omap_nand_info *info = nand_get_controller_data(chip);
@@ -368,7 +367,7 @@ static int _omap_calculate_ecc_bch(struct mtd_info
>>> *mtd, const u8 *dat,
case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
#endif
case OMAP_ECC_BCH8_CODE_HW:
- ptr = _cfg->bch_result_0_3[sector].bch_result_x[3];
+ ptr = _cfg->bch_result_0_3[0].bch_result_x[3];
val = readl(ptr);
ecc_code[i++] = (val >> 0) & 0xFF;
ptr--;
@@ -383,21 +382,21 @@ static int _omap_calculate_ecc_bch(struct
mtd_info *mtd, const u8 *dat,
break;
case OMAP_ECC_BCH16_CODE_HW:
- val =
readl(_cfg->bch_result_4_6[sector].bch_result_x[2]);
+ val =
+ readl(_cfg->bch_result_4_6[0].bch_result_x[2]);
ecc_code[i++] = (val >> 8) & 0xFF;
ecc_code[i++] = (val >> 0) & 0xFF;
- val =
readl(_cfg->bch_result_4_6[sector].bch_result_x[1]);
+ val =
+ readl(_cfg->bch_result_4_6[0].bch_result_x[1]);
ecc_code[i++] = (val >> 24) & 0xFF;
ecc_code[i++] = (val >> 16) & 0xFF;
ecc_code[i++] = (val >> 8) & 0xFF;
ecc_code[i++] = (val >> 0) & 0xFF;
- val =
Re: [PATCH 2/2] configs: j721e_evm_a72_defconfig: Switch to bootstd
Hi Neha, $sub: s/j721e/j721s2/ On 12:50-20231128, Neha Malcom Francis wrote: > Switch to using bootstd. Note that with this change, we will stop using > distro_bootcmd and instead depend entirely on bootflow method of > starting the system up. > > Also config_distro_bootcmd.h header file that is no longer needed in > j721s2_evm.h. > > Signed-off-by: Neha Malcom Francis > --- > configs/j721s2_evm_a72_defconfig | 5 +++-- > include/configs/j721s2_evm.h | 1 - > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/configs/j721s2_evm_a72_defconfig > b/configs/j721s2_evm_a72_defconfig > index a7adb9282b..04bc6a4449 100644 > --- a/configs/j721s2_evm_a72_defconfig > +++ b/configs/j721s2_evm_a72_defconfig > @@ -29,9 +29,10 @@ CONFIG_SPL_SPI=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_SPL_LOAD_FIT=y > CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 > -CONFIG_DISTRO_DEFAULTS=y > CONFIG_OF_SYSTEM_SETUP=y > -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;" > +CONFIG_BOOTSTD_FULL=y > +CONFIG_BOOTSTD_DEFAULTS=y > +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" Since we haven't yet figured out how to run remoteprocs with stdboot [0] can we keep `run boot_rprocs` also in this till that remoteproc stuff is figured out? Don't want to break existing compatibility that we have with this. [0]: https://lore.kernel.org/u-boot/20231106152205.GG496310@bill-the-cat/ Regards, Manorit > CONFIG_LOGLEVEL=7 > CONFIG_SPL_MAX_SIZE=0xc > CONFIG_SPL_HAS_BSS_LINKER_SECTION=y > diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h > index 692c6bb5e4..02673ae798 100644 > --- a/include/configs/j721s2_evm.h > +++ b/include/configs/j721s2_evm.h > @@ -10,7 +10,6 @@ > #define __CONFIG_J721S2_EVM_H > > #include > -#include > > /* DDR Configuration */ > #define CFG_SYS_SDRAM_BASE1 0x88000 > -- > 2.34.1 >
