Re: [PATCH] efi_loader: FMP cleanups
On Tue, Jun 15, 2021 at 08:23:35AM +0300, Ilias Apalodimas wrote: > On Tue, Jun 15, 2021 at 01:44:58PM +0900, AKASHI Takahiro wrote: > > On Tue, Jun 15, 2021 at 06:55:50AM +0300, Ilias Apalodimas wrote: > > > Akashi-san, > > > > > > On Tue, Jun 15, 2021 at 10:51:01AM +0900, AKASHI Takahiro wrote: > > > > Ilias, > > > > > > > > In this patch, you are trying to address a couple of independent > > > > issues in a single commit. > > > > Please split. > > > > (Heinrich doesn't like that.) > > > > Any comment? > > They are fixing the ESRT table generation, while cleaning up what's already > in > there. Besides Heinrich can comment himself if he wants them split or not. They are fixing "different" problems relating ESRT generation. That is my point. > > > > > > > On Mon, Jun 14, 2021 at 06:10:14PM +0300, Ilias Apalodimas wrote: > > > > > Right now we allow both of the FMPs (RAW and FIT based) to be > > > > > installed at > > > > > the same time. Moreover we only install those if a CapsuleUpdate is > > > > > requested. Since we now have an ESRT table, it makes more sense to > > > > > unconditionally install the FMP, so any userspace applications (e.g > > > > > fwupd) > > > > > can make use of them and trigger an update. > > > > > > > > > > While at it clean up the FMP installation as well. Chapter 23 of the > > > > > EFI > > > > > spec (rev 2.9) says: > > > > > "A specific updatable hardware firmware store must be represented by > > > > > exactly one FMP instance". > > > > > This is not the case for us, since both of our FMP protocols can be > > > > > installed at the same time and are controlled by a single > > > > > 'dfu_alt_info' > > > > > env variable. > > > > > So make the config option a choice and allow the user to install one > > > > > of them at any given time. > > > > > > > > I'd like to say nak in some respects: > > > > - Although I do understand the UEFI requirement that you mentioned > > > > above, > > > > FIT and RAW FMP drivers can handle *different* firmware even though > > > > they share the same dfu_alt_info. > > > > > > How ? > > > > One idea that I can imagine is that we may be able to utilize > > "update_image_index", which is currently not used effectively, > > in order to specify which firmware in dfu_alt_info be handled > > by either FIT FMP or RAW FMP. > > So it's not being used right now, and the fact is they are at the moment doing > the same thing. And even if it does, no one in his right mind will create a > platform and say "Hey let me create half of the capsules as raw and the rest > of them as FIT, it would be fun to watch users struggle". You misunderstand me. Because you asked me about an idea about how to fix the issue, I answered to it. I have never said that the current code does not have a problem that you mentioned. So I said: > > > > We should not impose unnecessary restriction if we manage to have some > > > > workaround to meet the requirement. ~~ > Is there anything very specific that you can achieve with FIT capsules that > you can't achieve with RAW ones (or vice versa), that would justify having > them both present at the same time? Yes. We may have different *firmware* for different software components and different devices. For example, You have firmare like U-Boot binary and default variable storage in different partitions. On the other hand, you have an extra firmware for a particular peripheral, like PCI device or anything else, which comes from a 3rd party vendor of the device. The former may and can be packed into a single binary in FIT format. The latter can be used in a separate RAW format as the timing of updating those firmware is likely to be different. > > > > > > We should not impose unnecessary restriction if we manage to have some > > > > workaround to meet the requirement. > > > > > > It's not the updating part only. It's that the .get_image_info also > > > relies on > > > the same env variable. > > > > The above idea can and should be applied to GetImageInfo implementation > > at the same time. > > Yes but can you do it with just changing the env variable now? Or you need to > add more code into the DFU logic? Those *meta* data for firmware can be declared/specified outside of FMP, and be referred to by FMP (and/or ESRT). That is what I meant by: > > > > (I still believe that the firmware definition for ESRT should exist > > > > elsewhere other than in FMP themselves.) > > > > > Specifically in the fwupd case on an RPI4 with the > > > dfu set at 'dfu_alt_info=u-boot.bin fat 0 1;' although 2 ERSTs entries > > > were > > > populated only one was reported. Probably because this really does give > > > you > > > 2 ways of updating the same flash. > > > > > > > (I still believe that the firmware definition for ESRT should exist > > > > elsewhere other than in FMP themselves.) > > > > > > That's a whole different story, and if we have that, then
[PATCH v2] riscv: andes_plic: Fix riscv_get_ipi() mask
Current logic in riscv_get_ipi() for Andes PLICSW does not look
correct. The mask to test IPI pending bits for a hart should be
left shifted by (8 * gd->arch.boot_hart), just the same as what
is done in riscv_send_ipi().
Fixes: 8b3e97badf97 ("riscv: add functions for reading the IPI status")
Signed-off-by: Bin Meng
Reviewed-by: Rick Chen
Tested-by: Rick Chen
---
Changes in v2:
- remove RFT tag
- update commit message with "Fixes" tag along with the commit id
arch/riscv/lib/andes_plic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
index 221a5fe324..5e113ee8c9 100644
--- a/arch/riscv/lib/andes_plic.c
+++ b/arch/riscv/lib/andes_plic.c
@@ -105,9 +105,11 @@ int riscv_clear_ipi(int hart)
int riscv_get_ipi(int hart, int *pending)
{
+ unsigned int ipi = (SEND_IPI_TO_HART(hart) << (8 * gd->arch.boot_hart));
+
*pending = readl((void __iomem *)PENDING_REG(gd->arch.plic,
gd->arch.boot_hart));
- *pending = !!(*pending & SEND_IPI_TO_HART(hart));
+ *pending = !!(*pending & ipi);
return 0;
}
--
2.25.1
Re: [PATCH 4/5] riscv: ae350: dts: Fix #interrupt-cells for plic0 in 32-bit
> From: Bin Meng > Sent: Friday, June 04, 2021 1:51 PM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; U-Boot Mailing List > Subject: [PATCH 4/5] riscv: ae350: dts: Fix #interrupt-cells for plic0 in > 32-bit > > All the device nodes that refer to plic0 as their interrupt parent have 2 > cells encoded in their interrupts property, but plic0 only provides 1 cell in > #interrupt-cells which is incorrect. > > Signed-off-by: Bin Meng > --- > > arch/riscv/dts/ae350_32.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Rick Chen
Re: [PATCH 3/5] riscv: ae350: dts: Remove the unnecessary #address-cells in plic nodes
> From: Bin Meng > Sent: Friday, June 04, 2021 1:51 PM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; U-Boot Mailing List > Subject: [PATCH 3/5] riscv: ae350: dts: Remove the unnecessary #address-cells > in plic nodes > > PLIC nodes don't have child nodes, so #address-cells is not needed. > > Signed-off-by: Bin Meng > --- > > arch/riscv/dts/ae350_32.dts | 2 -- > arch/riscv/dts/ae350_64.dts | 2 -- > 2 files changed, 4 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH] efi_loader: FMP cleanups
On Tue, Jun 15, 2021 at 01:44:58PM +0900, AKASHI Takahiro wrote: > On Tue, Jun 15, 2021 at 06:55:50AM +0300, Ilias Apalodimas wrote: > > Akashi-san, > > > > On Tue, Jun 15, 2021 at 10:51:01AM +0900, AKASHI Takahiro wrote: > > > Ilias, > > > > > > In this patch, you are trying to address a couple of independent > > > issues in a single commit. > > > Please split. > > > (Heinrich doesn't like that.) > > Any comment? They are fixing the ESRT table generation, while cleaning up what's already in there. Besides Heinrich can comment himself if he wants them split or not. > > > > On Mon, Jun 14, 2021 at 06:10:14PM +0300, Ilias Apalodimas wrote: > > > > Right now we allow both of the FMPs (RAW and FIT based) to be installed > > > > at > > > > the same time. Moreover we only install those if a CapsuleUpdate is > > > > requested. Since we now have an ESRT table, it makes more sense to > > > > unconditionally install the FMP, so any userspace applications (e.g > > > > fwupd) > > > > can make use of them and trigger an update. > > > > > > > > While at it clean up the FMP installation as well. Chapter 23 of the > > > > EFI > > > > spec (rev 2.9) says: > > > > "A specific updatable hardware firmware store must be represented by > > > > exactly one FMP instance". > > > > This is not the case for us, since both of our FMP protocols can be > > > > installed at the same time and are controlled by a single 'dfu_alt_info' > > > > env variable. > > > > So make the config option a choice and allow the user to install one > > > > of them at any given time. > > > > > > I'd like to say nak in some respects: > > > - Although I do understand the UEFI requirement that you mentioned above, > > > FIT and RAW FMP drivers can handle *different* firmware even though > > > they share the same dfu_alt_info. > > > > How ? > > One idea that I can imagine is that we may be able to utilize > "update_image_index", which is currently not used effectively, > in order to specify which firmware in dfu_alt_info be handled > by either FIT FMP or RAW FMP. So it's not being used right now, and the fact is they are at the moment doing the same thing. And even if it does, no one in his right mind will create a platform and say "Hey let me create half of the capsules as raw and the rest of them as FIT, it would be fun to watch users struggle". Is there anything very specific that you can achieve with FIT capsules that you can't achieve with RAW ones (or vice versa), that would justify having them both present at the same time? > > > > We should not impose unnecessary restriction if we manage to have some > > > workaround to meet the requirement. > > > > It's not the updating part only. It's that the .get_image_info also relies > > on > > the same env variable. > > The above idea can and should be applied to GetImageInfo implementation > at the same time. Yes but can you do it with just changing the env variable now? Or you need to add more code into the DFU logic? > > > Specifically in the fwupd case on an RPI4 with the > > dfu set at 'dfu_alt_info=u-boot.bin fat 0 1;' although 2 ERSTs entries were > > populated only one was reported. Probably because this really does give > > you > > 2 ways of updating the same flash. > > > > > (I still believe that the firmware definition for ESRT should exist > > > elsewhere other than in FMP themselves.) > > > > That's a whole different story, and if we have that, then .get_image_info > > should change as well instead of using the DFU information. > > I don't think so as I mentioned above. And I don't see any benefit from storing the same information in 2 completely disjoint entities. > > > Because right > > now we enabled security (or think we have), while allowing users to set an > > env > > variable which is not authenticated, and completely change what the > > firmware reports (or updates). > > This is the point that I mentioned earlier in our private chat, > and it's a "whole different" story in this context. You mentioned that in the context of "can we install the FMPs during the EFI init". Since the variable is interpreted at runtime, we definitely can. I looked back at that chat and saw nothing related to the security problems we'll create. In any case the problem here is real, but there are sane ways to avoid it. > > > We can always add a huge warning saying > > something along the lines of "If you really care this should come with a > > CONFIG_ENV_IS_NOWHERE and a boot timeout set to -1". > > > > The spec is pretty clear and we allow users to *break* it with a config > > option. Arguably this is fine, since the code continues to work fine and > > you can perform the updates, but in essence RAW and FITs are used to update > > the same medium right now. You can't have a capsule with half it's contents > > describing something RAW and the other half being a FIT. You have a FIT > > based > > capsule or a RAW based capsule. > > See above. I still
Re: [PATCH u-boot-marvell] arm: mvebu: turris_{omnia,mox}: ensure running bootcmd_rescue always works
On 14.06.21 16:45, Marek Behún wrote:
From: Pali Rohár
One of the points of putting the rescue boot command into default
environment is that user can invoke it without physical access to the
board (without having to press the factory reset button), by running
run bootcmd_rescue
in U-Boot's console.
Therefore we have to ensure that bootcmd_rescue is always set to default
value, regardless of whether the factory reset button was pressed.
Otherwise the variable will be empty for example after upgrade from
previous U-Boot.
Fixes: ec3784d62646 ("arm: mvebu: turris_mox: add support for board rescue
mode")
Fixes: 176c3e7760a2 ("arm: mvebu: turris_omnia: support invoking rescue boot from
console")
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
board/CZ.NIC/turris_mox/turris_mox.c | 14 +++---
board/CZ.NIC/turris_omnia/turris_omnia.c | 13 ++---
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/board/CZ.NIC/turris_mox/turris_mox.c
b/board/CZ.NIC/turris_mox/turris_mox.c
index 44c272c7cb..428cd23a19 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -440,10 +440,18 @@ static bool read_reset_button(void)
static void handle_reset_button(void)
{
+ const char * const vars[1] = { "bootcmd_rescue", };
+
+ /*
+* Ensure that bootcmd_rescue has always stock value, so that running
+* run bootcmd_rescue
+* always works correctly.
+*/
+ env_set_default_vars(1, (char * const *)vars, 0);
+
if (read_reset_button()) {
- const char * const vars[3] = {
+ const char * const vars[2] = {
"bootcmd",
- "bootcmd_rescue",
"distro_bootcmd",
};
@@ -451,7 +459,7 @@ static void handle_reset_button(void)
* Set the above envs to their default values, in case the user
* managed to break them.
*/
- env_set_default_vars(3, (char * const *)vars, 0);
+ env_set_default_vars(2, (char * const *)vars, 0);
/* Ensure bootcmd_rescue is used by distroboot */
env_set("boot_targets", "rescue");
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index ade923f599..8b2f94f959 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -339,9 +339,17 @@ static int set_regdomain(void)
static void handle_reset_button(void)
{
+ const char * const vars[1] = { "bootcmd_rescue", };
int ret;
u8 reset_status;
+ /*
+* Ensure that bootcmd_rescue has always stock value, so that running
+* run bootcmd_rescue
+* always works correctly.
+*/
+ env_set_default_vars(1, (char * const *)vars, 0);
+
ret = omnia_mcu_read(CMD_GET_RESET, _status, 1);
if (ret) {
printf("omnia_mcu_read failed: %i, reset status unknown!\n",
@@ -352,9 +360,8 @@ static void handle_reset_button(void)
env_set_ulong("omnia_reset", reset_status);
if (reset_status) {
- const char * const vars[3] = {
+ const char * const vars[2] = {
"bootcmd",
- "bootcmd_rescue",
"distro_bootcmd",
};
@@ -362,7 +369,7 @@ static void handle_reset_button(void)
* Set the above envs to their default values, in case the user
* managed to break them.
*/
- env_set_default_vars(3, (char * const *)vars, 0);
+ env_set_default_vars(2, (char * const *)vars, 0);
/* Ensure bootcmd_rescue is used by distroboot */
env_set("boot_targets", "rescue");
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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: [PATCH] efi_loader: FMP cleanups
On Tue, Jun 15, 2021 at 06:55:50AM +0300, Ilias Apalodimas wrote: > Akashi-san, > > On Tue, Jun 15, 2021 at 10:51:01AM +0900, AKASHI Takahiro wrote: > > Ilias, > > > > In this patch, you are trying to address a couple of independent > > issues in a single commit. > > Please split. > > (Heinrich doesn't like that.) Any comment? > > On Mon, Jun 14, 2021 at 06:10:14PM +0300, Ilias Apalodimas wrote: > > > Right now we allow both of the FMPs (RAW and FIT based) to be installed at > > > the same time. Moreover we only install those if a CapsuleUpdate is > > > requested. Since we now have an ESRT table, it makes more sense to > > > unconditionally install the FMP, so any userspace applications (e.g fwupd) > > > can make use of them and trigger an update. > > > > > > While at it clean up the FMP installation as well. Chapter 23 of the EFI > > > spec (rev 2.9) says: > > > "A specific updatable hardware firmware store must be represented by > > > exactly one FMP instance". > > > This is not the case for us, since both of our FMP protocols can be > > > installed at the same time and are controlled by a single 'dfu_alt_info' > > > env variable. > > > So make the config option a choice and allow the user to install one > > > of them at any given time. > > > > I'd like to say nak in some respects: > > - Although I do understand the UEFI requirement that you mentioned above, > > FIT and RAW FMP drivers can handle *different* firmware even though > > they share the same dfu_alt_info. > > How ? One idea that I can imagine is that we may be able to utilize "update_image_index", which is currently not used effectively, in order to specify which firmware in dfu_alt_info be handled by either FIT FMP or RAW FMP. > > We should not impose unnecessary restriction if we manage to have some > > workaround to meet the requirement. > > It's not the updating part only. It's that the .get_image_info also relies on > the same env variable. The above idea can and should be applied to GetImageInfo implementation at the same time. > Specifically in the fwupd case on an RPI4 with the > dfu set at 'dfu_alt_info=u-boot.bin fat 0 1;' although 2 ERSTs entries were > populated only one was reported. Probably because this really does give you > 2 ways of updating the same flash. > > > (I still believe that the firmware definition for ESRT should exist > > elsewhere other than in FMP themselves.) > > That's a whole different story, and if we have that, then .get_image_info > should change as well instead of using the DFU information. I don't think so as I mentioned above. > Because right > now we enabled security (or think we have), while allowing users to set an env > variable which is not authenticated, and completely change what the > firmware reports (or updates). This is the point that I mentioned earlier in our private chat, and it's a "whole different" story in this context. > We can always add a huge warning saying > something along the lines of "If you really care this should come with a > CONFIG_ENV_IS_NOWHERE and a boot timeout set to -1". > > The spec is pretty clear and we allow users to *break* it with a config > option. Arguably this is fine, since the code continues to work fine and > you can perform the updates, but in essence RAW and FITs are used to update > the same medium right now. You can't have a capsule with half it's contents > describing something RAW and the other half being a FIT. You have a FIT > based > capsule or a RAW based capsule. See above. > > - We should allow users to add their own FMP drivers and so not call > > [arch_]efi_load_capsule_drivers() unconditionally > > even if you don't like "__weak" attribute. > > I am fine with the __weak attribute. On the other hand I consider the > current code the defacto way users would use to update their firmware. That's > why I removed the __weak attribute. If a hardware vendor was to update > their special PCI option ROM or a flash that lives on the secure world they > should install their FMPs on a different handle and leave the current code > as is. And we should provide an option that disables these existing handle. > > - Selecting only one of FIT and RAW FMPs in sandbox*_defconfig will > > leave some test cases in pytest skipped. > > Yea that's unfortunate, but maybe we can just add an extra config on the > sandbox? Please add another patch that is missing. -Takahiro Akashi > Thanks > /Ilias > > > > > -Takahiro Akashi > > > > > The overall changes show up in fwupd > > > > > > pre-patch: > > > fwupdmgr get-devices > > > No detected devices > > > > > > post-patch (with FIT FMP installed): > > > fwupdmgr get-devices > > > WARNING: Required efivarfs filesystem was not found > > > See https://github.com/fwupd/fwupd/wiki/PluginFlag:efivar-not-mounted > > > for more information. > > > Unknown Product > > > │ > > > └─Unknown Firmware: > > > Device ID: 605080e08f71dabb86d0781c28f7d923edabf7d6
Re: [PATCH] efi_loader: FMP cleanups
On Tue, Jun 15, 2021 at 09:49:58AM +0900, Masami Hiramatsu wrote:
> 2021年6月15日(火) 0:10 Ilias Apalodimas :
>
> >
> > Right now we allow both of the FMPs (RAW and FIT based) to be installed at
> > the same time. Moreover we only install those if a CapsuleUpdate is
> > requested. Since we now have an ESRT table, it makes more sense to
> > unconditionally install the FMP, so any userspace applications (e.g fwupd)
> > can make use of them and trigger an update.
> >
> > While at it clean up the FMP installation as well. Chapter 23 of the EFI
> > spec (rev 2.9) says:
> > "A specific updatable hardware firmware store must be represented by
> > exactly one FMP instance".
> > This is not the case for us, since both of our FMP protocols can be
> > installed at the same time and are controlled by a single 'dfu_alt_info'
> > env variable.
> > So make the config option a choice and allow the user to install one
> > of them at any given time.
> >
> > The overall changes show up in fwupd
> >
> > pre-patch:
> > fwupdmgr get-devices
> > No detected devices
> >
> > post-patch (with FIT FMP installed):
> > fwupdmgr get-devices
> > WARNING: Required efivarfs filesystem was not found
> > See https://github.com/fwupd/fwupd/wiki/PluginFlag:efivar-not-mounted for
> > more information.
> > Unknown Product
> > │
> > └─Unknown Firmware:
> > Device ID: 605080e08f71dabb86d0781c28f7d923edabf7d6
> > Current version:0
> > Vendor: DMI:U-Boot
> > Update Error: Not updatable as efivarfs was not found
> > GUIDs: ae13ff2d-9ad4-4e25-9ac8-6d80b3b22147
> > 230c8b18-8d9b-53ec-838b-6cfc0383493a ←
> > main-system-firmware
> > 1a1da7d4-0a24-51b5-8a1a-1e3274328094 ←
> > UEFI\RES_{AE13FF2D-9AD4-4E25-9AC8-6D80B3B22147}
> > Device Flags: • Internal device
> > • System requires external power source
> > • Needs a reboot after installation
> > • Device is usable for the duration of the update
> >
>
> This looks good to me, and this covers one patch which I sent before.
> https://lists.denx.de/pipermail/u-boot/2021-June/451401.html
>
> Reviewed-by: Masami Hiramatsu
Thanks Masami. I'll send a v2 regardless since I am missing an IS_ENABLED
option when trying to install the FMPs
Cheers
/Ilias
>
> Thank you!
>
> > Signed-off-by: Ilias Apalodimas
> > ---
> > configs/sandbox64_defconfig | 1 -
> > configs/sandbox_defconfig| 1 -
> > configs/xilinx_zynqmp_virt_defconfig | 1 -
> > include/efi_loader.h | 1 +
> > lib/efi_loader/Kconfig | 48 +++-
> > lib/efi_loader/efi_capsule.c | 22 -
> > lib/efi_loader/efi_setup.c | 4 +++
> > 7 files changed, 37 insertions(+), 41 deletions(-)
> >
> > diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
> > index 9a373bab6fe3..af18b6c7826e 100644
> > --- a/configs/sandbox64_defconfig
> > +++ b/configs/sandbox64_defconfig
> > @@ -233,7 +233,6 @@ CONFIG_LZ4=y
> > CONFIG_ERRNO_STR=y
> > CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> > CONFIG_EFI_CAPSULE_ON_DISK=y
> > -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> > CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> > CONFIG_EFI_SECURE_BOOT=y
> > CONFIG_TEST_FDTDEC=y
> > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> > index bdbf714e2bd9..24313fdfa53d 100644
> > --- a/configs/sandbox_defconfig
> > +++ b/configs/sandbox_defconfig
> > @@ -280,7 +280,6 @@ CONFIG_LZ4=y
> > CONFIG_ERRNO_STR=y
> > CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> > CONFIG_EFI_CAPSULE_ON_DISK=y
> > -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> > CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> > CONFIG_EFI_SECURE_BOOT=y
> > CONFIG_TEST_FDTDEC=y
> > diff --git a/configs/xilinx_zynqmp_virt_defconfig
> > b/configs/xilinx_zynqmp_virt_defconfig
> > index e939b04ef6a5..0c2d1a70a5a1 100644
> > --- a/configs/xilinx_zynqmp_virt_defconfig
> > +++ b/configs/xilinx_zynqmp_virt_defconfig
> > @@ -188,5 +188,4 @@ CONFIG_EFI_SET_TIME=y
> > CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> > CONFIG_EFI_CAPSULE_ON_DISK=y
> > CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y
> > -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> > CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 0a9c82a257e1..b81180cfda8b 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -972,4 +972,5 @@ efi_status_t efi_esrt_register(void);
> > * - error code otherwise.
> > */
> > efi_status_t efi_esrt_populate(void);
> > +efi_status_t efi_load_capsule_drivers(void);
> > #endif /* _EFI_LOADER_H */
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 6242caceb7f9..da6f5faf5adb 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -161,6 +161,31 @@ config EFI_CAPSULE_FIRMWARE_MANAGEMENT
> > Select this option if you want to
Re: [PATCH] efi_loader: FMP cleanups
Akashi-san,
On Tue, Jun 15, 2021 at 10:51:01AM +0900, AKASHI Takahiro wrote:
> Ilias,
>
> In this patch, you are trying to address a couple of independent
> issues in a single commit.
> Please split.
> (Heinrich doesn't like that.)
>
> On Mon, Jun 14, 2021 at 06:10:14PM +0300, Ilias Apalodimas wrote:
> > Right now we allow both of the FMPs (RAW and FIT based) to be installed at
> > the same time. Moreover we only install those if a CapsuleUpdate is
> > requested. Since we now have an ESRT table, it makes more sense to
> > unconditionally install the FMP, so any userspace applications (e.g fwupd)
> > can make use of them and trigger an update.
> >
> > While at it clean up the FMP installation as well. Chapter 23 of the EFI
> > spec (rev 2.9) says:
> > "A specific updatable hardware firmware store must be represented by
> > exactly one FMP instance".
> > This is not the case for us, since both of our FMP protocols can be
> > installed at the same time and are controlled by a single 'dfu_alt_info'
> > env variable.
> > So make the config option a choice and allow the user to install one
> > of them at any given time.
>
> I'd like to say nak in some respects:
> - Although I do understand the UEFI requirement that you mentioned above,
> FIT and RAW FMP drivers can handle *different* firmware even though
> they share the same dfu_alt_info.
How ?
> We should not impose unnecessary restriction if we manage to have some
> workaround to meet the requirement.
It's not the updating part only. It's that the .get_image_info also relies on
the same env variable. Specifically in the fwupd case on an RPI4 with the
dfu set at 'dfu_alt_info=u-boot.bin fat 0 1;' although 2 ERSTs entries were
populated only one was reported. Probably because this really does give you
2 ways of updating the same flash.
> (I still believe that the firmware definition for ESRT should exist
> elsewhere other than in FMP themselves.)
That's a whole different story, and if we have that, then .get_image_info
should change as well instead of using the DFU information. Because right
now we enabled security (or think we have), while allowing users to set an env
variable which is not authenticated, and completely change what the
firmware reports (or updates). We can always add a huge warning saying
something along the lines of "If you really care this should come with a
CONFIG_ENV_IS_NOWHERE and a boot timeout set to -1".
The spec is pretty clear and we allow users to *break* it with a config
option. Arguably this is fine, since the code continues to work fine and
you can perform the updates, but in essence RAW and FITs are used to update
the same medium right now. You can't have a capsule with half it's contents
describing something RAW and the other half being a FIT. You have a FIT based
capsule or a RAW based capsule.
> - We should allow users to add their own FMP drivers and so not call
> [arch_]efi_load_capsule_drivers() unconditionally
> even if you don't like "__weak" attribute.
I am fine with the __weak attribute. On the other hand I consider the
current code the defacto way users would use to update their firmware. That's
why I removed the __weak attribute. If a hardware vendor was to update
their special PCI option ROM or a flash that lives on the secure world they
should install their FMPs on a different handle and leave the current code
as is.
> - Selecting only one of FIT and RAW FMPs in sandbox*_defconfig will
> leave some test cases in pytest skipped.
Yea that's unfortunate, but maybe we can just add an extra config on the
sandbox?
Thanks
/Ilias
>
> -Takahiro Akashi
>
> > The overall changes show up in fwupd
> >
> > pre-patch:
> > fwupdmgr get-devices
> > No detected devices
> >
> > post-patch (with FIT FMP installed):
> > fwupdmgr get-devices
> > WARNING: Required efivarfs filesystem was not found
> > See https://github.com/fwupd/fwupd/wiki/PluginFlag:efivar-not-mounted for
> > more information.
> > Unknown Product
> > │
> > └─Unknown Firmware:
> > Device ID: 605080e08f71dabb86d0781c28f7d923edabf7d6
> > Current version:0
> > Vendor: DMI:U-Boot
> > Update Error: Not updatable as efivarfs was not found
> > GUIDs: ae13ff2d-9ad4-4e25-9ac8-6d80b3b22147
> > 230c8b18-8d9b-53ec-838b-6cfc0383493a ←
> > main-system-firmware
> > 1a1da7d4-0a24-51b5-8a1a-1e3274328094 ←
> > UEFI\RES_{AE13FF2D-9AD4-4E25-9AC8-6D80B3B22147}
> > Device Flags: • Internal device
> > • System requires external power source
> > • Needs a reboot after installation
> > • Device is usable for the duration of the update
> >
> > Signed-off-by: Ilias Apalodimas
> > ---
> > configs/sandbox64_defconfig | 1 -
> > configs/sandbox_defconfig| 1 -
> > configs/xilinx_zynqmp_virt_defconfig |
Re: [PATCH 1/5] riscv: ae350: dts: Add SPDX license header
> From: Bin Meng > Sent: Friday, June 04, 2021 1:51 PM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; U-Boot Mailing List > Subject: [PATCH 1/5] riscv: ae350: dts: Add SPDX license header > > The SPDX license header is currently missing. Add one. > > Signed-off-by: Bin Meng > --- > > arch/riscv/dts/ae350_32.dts | 2 ++ > arch/riscv/dts/ae350_64.dts | 2 ++ > 2 files changed, 4 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH 5/5] riscv: ae350: dts: Add missing "u-boot,dm-spl" for SPL config
> Hi Rick, > > On Sat, Jun 12, 2021 at 9:30 PM Rick Chen wrote: > > > > HI Bin > > > > > Hi Rick, > > > > > > On Wed, Jun 9, 2021 at 3:06 PM Rick Chen wrote: > > > > > > > > Hi Bin, > > > > > > > > > From: Bin Meng > > > > > Sent: Friday, June 04, 2021 1:51 PM > > > > > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi > > > > > Liang(梁育齊) ; U-Boot Mailing List > > > > > > > > > > Subject: [PATCH 5/5] riscv: ae350: dts: Add missing "u-boot,dm-spl" > > > > > for SPL config > > > > > > > > > > At present the AE350 SPL defconfig is using OF_PRIOR_STAGE. The > > > > > intention was to use gdb to load device tree before running U-Boot > > > > > SPL/proper from RAM. When we switch to OF_SEPARATE we will have to > > > > > use our own DT but without "u-boot,dm-spl" in several essential > > > > > nodes, SPL does not boot. > > > > > > > > Can you describe how do you verify and provide the steps about that > > > > SPL boot fail that I can duplicate it. :) > > > > > > $ make ae350_rv64_spl_defconfig; make -j > > > $ make menuconfig (change OF_PRIOR_STAGE to OF_EMBED or OF_SEPARATE) > > > > > > Load u-boot.bin to RAM > > > > It can boot with OF_EMBED. > > But it compile fail with choosing OF_EMBED at the first time, fail > > messages as below: > > > > binman: [Errno 2] No such file or directory: 'u-boot.dtb' > > Makefile:1084: recipe for target 'all' failed > > make: *** [all] Error 1 > > Yes, this is a known issue of the binman conversion for SPL. OF_EMBED > is a debugging purpose hence I am inclined to leave it as is. Reviewed-by: Rick Chen > > Regards, > Bin
Re: [RFT PATCH] riscv: andes_plic: Fix riscv_get_ipi() mask
Hi Bin > From: Bin Meng > Sent: Monday, June 14, 2021 11:48 AM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; U-Boot Mailing List > Subject: Re: [RFT PATCH] riscv: andes_plic: Fix riscv_get_ipi() mask > > On Wed, Jun 9, 2021 at 3:55 PM Bin Meng wrote: > > > > Current logic in riscv_get_ipi() for Andes PLICSW does not look good > > to me. The mask to test IPI pending bits for a hart should be left > > shifted by (8 * gd->arch.boot_hart), just the same as what is done in > > riscv_send_ipi(). > > > > Signed-off-by: Bin Meng > > > > --- > > It looks there is no datasheet released from Andes that describes how > > PLICSW works, and its register fields. I can only get an understanding > > from current U-Boot and OpenSBI PLICSW driver. > > > > This requires testing on Andes hardware, which I don't have access to. > > > > arch/riscv/lib/andes_plic.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > Ping? Though there will be only one hart will jump to U-Boot proper currently, and this delay loop seem to be unnecessary. But it is still a good catch. Thanks, Rick Tested-by: Rick Chen Reviewed-by: Rick Chen
Re: [PATCH] efi_loader: FMP cleanups
Ilias,
In this patch, you are trying to address a couple of independent
issues in a single commit.
Please split.
(Heinrich doesn't like that.)
On Mon, Jun 14, 2021 at 06:10:14PM +0300, Ilias Apalodimas wrote:
> Right now we allow both of the FMPs (RAW and FIT based) to be installed at
> the same time. Moreover we only install those if a CapsuleUpdate is
> requested. Since we now have an ESRT table, it makes more sense to
> unconditionally install the FMP, so any userspace applications (e.g fwupd)
> can make use of them and trigger an update.
>
> While at it clean up the FMP installation as well. Chapter 23 of the EFI
> spec (rev 2.9) says:
> "A specific updatable hardware firmware store must be represented by
> exactly one FMP instance".
> This is not the case for us, since both of our FMP protocols can be
> installed at the same time and are controlled by a single 'dfu_alt_info'
> env variable.
> So make the config option a choice and allow the user to install one
> of them at any given time.
I'd like to say nak in some respects:
- Although I do understand the UEFI requirement that you mentioned above,
FIT and RAW FMP drivers can handle *different* firmware even though
they share the same dfu_alt_info.
We should not impose unnecessary restriction if we manage to have some
workaround to meet the requirement.
(I still believe that the firmware definition for ESRT should exist
elsewhere other than in FMP themselves.)
- We should allow users to add their own FMP drivers and so not call
[arch_]efi_load_capsule_drivers() unconditionally
even if you don't like "__weak" attribute.
- Selecting only one of FIT and RAW FMPs in sandbox*_defconfig will
leave some test cases in pytest skipped.
-Takahiro Akashi
> The overall changes show up in fwupd
>
> pre-patch:
> fwupdmgr get-devices
> No detected devices
>
> post-patch (with FIT FMP installed):
> fwupdmgr get-devices
> WARNING: Required efivarfs filesystem was not found
> See https://github.com/fwupd/fwupd/wiki/PluginFlag:efivar-not-mounted for
> more information.
> Unknown Product
> │
> └─Unknown Firmware:
> Device ID: 605080e08f71dabb86d0781c28f7d923edabf7d6
> Current version:0
> Vendor: DMI:U-Boot
> Update Error: Not updatable as efivarfs was not found
> GUIDs: ae13ff2d-9ad4-4e25-9ac8-6d80b3b22147
> 230c8b18-8d9b-53ec-838b-6cfc0383493a ←
> main-system-firmware
> 1a1da7d4-0a24-51b5-8a1a-1e3274328094 ←
> UEFI\RES_{AE13FF2D-9AD4-4E25-9AC8-6D80B3B22147}
> Device Flags: • Internal device
> • System requires external power source
> • Needs a reboot after installation
> • Device is usable for the duration of the update
>
> Signed-off-by: Ilias Apalodimas
> ---
> configs/sandbox64_defconfig | 1 -
> configs/sandbox_defconfig| 1 -
> configs/xilinx_zynqmp_virt_defconfig | 1 -
> include/efi_loader.h | 1 +
> lib/efi_loader/Kconfig | 48 +++-
> lib/efi_loader/efi_capsule.c | 22 -
> lib/efi_loader/efi_setup.c | 4 +++
> 7 files changed, 37 insertions(+), 41 deletions(-)
>
> diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
> index 9a373bab6fe3..af18b6c7826e 100644
> --- a/configs/sandbox64_defconfig
> +++ b/configs/sandbox64_defconfig
> @@ -233,7 +233,6 @@ CONFIG_LZ4=y
> CONFIG_ERRNO_STR=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> CONFIG_EFI_SECURE_BOOT=y
> CONFIG_TEST_FDTDEC=y
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index bdbf714e2bd9..24313fdfa53d 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -280,7 +280,6 @@ CONFIG_LZ4=y
> CONFIG_ERRNO_STR=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> CONFIG_EFI_SECURE_BOOT=y
> CONFIG_TEST_FDTDEC=y
> diff --git a/configs/xilinx_zynqmp_virt_defconfig
> b/configs/xilinx_zynqmp_virt_defconfig
> index e939b04ef6a5..0c2d1a70a5a1 100644
> --- a/configs/xilinx_zynqmp_virt_defconfig
> +++ b/configs/xilinx_zynqmp_virt_defconfig
> @@ -188,5 +188,4 @@ CONFIG_EFI_SET_TIME=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 0a9c82a257e1..b81180cfda8b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -972,4 +972,5 @@ efi_status_t efi_esrt_register(void);
> * - error code otherwise.
> */
> efi_status_t efi_esrt_populate(void);
> +efi_status_t efi_load_capsule_drivers(void);
>
Re: [PATCH] efi_loader: FMP cleanups
2021年6月15日(火) 0:10 Ilias Apalodimas :
>
> Right now we allow both of the FMPs (RAW and FIT based) to be installed at
> the same time. Moreover we only install those if a CapsuleUpdate is
> requested. Since we now have an ESRT table, it makes more sense to
> unconditionally install the FMP, so any userspace applications (e.g fwupd)
> can make use of them and trigger an update.
>
> While at it clean up the FMP installation as well. Chapter 23 of the EFI
> spec (rev 2.9) says:
> "A specific updatable hardware firmware store must be represented by
> exactly one FMP instance".
> This is not the case for us, since both of our FMP protocols can be
> installed at the same time and are controlled by a single 'dfu_alt_info'
> env variable.
> So make the config option a choice and allow the user to install one
> of them at any given time.
>
> The overall changes show up in fwupd
>
> pre-patch:
> fwupdmgr get-devices
> No detected devices
>
> post-patch (with FIT FMP installed):
> fwupdmgr get-devices
> WARNING: Required efivarfs filesystem was not found
> See https://github.com/fwupd/fwupd/wiki/PluginFlag:efivar-not-mounted for
> more information.
> Unknown Product
> │
> └─Unknown Firmware:
> Device ID: 605080e08f71dabb86d0781c28f7d923edabf7d6
> Current version:0
> Vendor: DMI:U-Boot
> Update Error: Not updatable as efivarfs was not found
> GUIDs: ae13ff2d-9ad4-4e25-9ac8-6d80b3b22147
> 230c8b18-8d9b-53ec-838b-6cfc0383493a ←
> main-system-firmware
> 1a1da7d4-0a24-51b5-8a1a-1e3274328094 ←
> UEFI\RES_{AE13FF2D-9AD4-4E25-9AC8-6D80B3B22147}
> Device Flags: • Internal device
> • System requires external power source
> • Needs a reboot after installation
> • Device is usable for the duration of the update
>
This looks good to me, and this covers one patch which I sent before.
https://lists.denx.de/pipermail/u-boot/2021-June/451401.html
Reviewed-by: Masami Hiramatsu
Thank you!
> Signed-off-by: Ilias Apalodimas
> ---
> configs/sandbox64_defconfig | 1 -
> configs/sandbox_defconfig| 1 -
> configs/xilinx_zynqmp_virt_defconfig | 1 -
> include/efi_loader.h | 1 +
> lib/efi_loader/Kconfig | 48 +++-
> lib/efi_loader/efi_capsule.c | 22 -
> lib/efi_loader/efi_setup.c | 4 +++
> 7 files changed, 37 insertions(+), 41 deletions(-)
>
> diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
> index 9a373bab6fe3..af18b6c7826e 100644
> --- a/configs/sandbox64_defconfig
> +++ b/configs/sandbox64_defconfig
> @@ -233,7 +233,6 @@ CONFIG_LZ4=y
> CONFIG_ERRNO_STR=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> CONFIG_EFI_SECURE_BOOT=y
> CONFIG_TEST_FDTDEC=y
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index bdbf714e2bd9..24313fdfa53d 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -280,7 +280,6 @@ CONFIG_LZ4=y
> CONFIG_ERRNO_STR=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> CONFIG_EFI_SECURE_BOOT=y
> CONFIG_TEST_FDTDEC=y
> diff --git a/configs/xilinx_zynqmp_virt_defconfig
> b/configs/xilinx_zynqmp_virt_defconfig
> index e939b04ef6a5..0c2d1a70a5a1 100644
> --- a/configs/xilinx_zynqmp_virt_defconfig
> +++ b/configs/xilinx_zynqmp_virt_defconfig
> @@ -188,5 +188,4 @@ CONFIG_EFI_SET_TIME=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 0a9c82a257e1..b81180cfda8b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -972,4 +972,5 @@ efi_status_t efi_esrt_register(void);
> * - error code otherwise.
> */
> efi_status_t efi_esrt_populate(void);
> +efi_status_t efi_load_capsule_drivers(void);
> #endif /* _EFI_LOADER_H */
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 6242caceb7f9..da6f5faf5adb 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -161,6 +161,31 @@ config EFI_CAPSULE_FIRMWARE_MANAGEMENT
> Select this option if you want to enable capsule-based
> firmware update using Firmware Management Protocol.
>
> +choice EFI_CAPSULE_TYPE
> + prompt "Capsule type (RAW/FIT)"
> + depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
> +
> +config EFI_CAPSULE_FIRMWARE_FIT
> + bool "FMP driver for FIT images"
> + depends on FIT
> + select UPDATE_FIT
> + select DFU
> + select EFI_CAPSULE_FIRMWARE
> + help
> +
Re: [PATCH 4/6] imx8m: Restrict usable memory to space below 4G boundary
On 6/15/21 2:28 AM, Peng Fan (OSS) wrote: On 2021/6/7 20:38, Marek Vasut wrote: On 6/7/21 2:05 PM, Frieder Schrempf wrote: From: Frieder Schrempf Some IPs have their accessible address space restricted by the interconnect. Let's make sure U-Boot only ever uses the space below the 4G address boundary (which is 3GiB big), even when the effective available memory is bigger. We implement board_get_usable_ram_top() for all i.MX8M SoCs, as the whole family is affected by this. Shouldn't only those specific IP drivers handle buffers in the 64bit space somehow ? E.g. using a bounce buffer ? That could cause extra mem copy. If you want to avoid the extra memcopy, then make sure the buffers are not allocated above 4 GiB boundary. Then the bounce buffer does no copy. This board_get_usable_ram_top() is just a temporary workaround for platforms with broken drivers which are not fixed yet, so please fix the drivers instead. Bounce buffer would be good for systems that take U-Boot as UEFI firmware, because U-Boot would be located at high end, but in the middle just top of 4GB. The bounce buffer is a necessity for IPs which cannot address more than the 4 GiB of memory. In fact, it would be even better to handle DT dma-ranges, but that is the next step. I not object this patch, but it also be good if bounce buffer be added for improvement. Reviewed-by: Peng Fan I do object to this, since it increases the proliferation of this broken board_get_usable_ram_top() workaround instead of fixing the drivers properly.
Re: [PATCH 4/6] imx8m: Restrict usable memory to space below 4G boundary
On 2021/6/7 20:38, Marek Vasut wrote: On 6/7/21 2:05 PM, Frieder Schrempf wrote: From: Frieder Schrempf Some IPs have their accessible address space restricted by the interconnect. Let's make sure U-Boot only ever uses the space below the 4G address boundary (which is 3GiB big), even when the effective available memory is bigger. We implement board_get_usable_ram_top() for all i.MX8M SoCs, as the whole family is affected by this. Shouldn't only those specific IP drivers handle buffers in the 64bit space somehow ? E.g. using a bounce buffer ? That could cause extra mem copy. Bounce buffer would be good for systems that take U-Boot as UEFI firmware, because U-Boot would be located at high end, but in the middle just top of 4GB. I not object this patch, but it also be good if bounce buffer be added for improvement. Reviewed-by: Peng Fan
Re: [PATCH v2] Revert "mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output"
Hi Fabio On 2021/6/8 10:07, Fabio Estevam wrote: Hi Haibo, On Mon, Jun 7, 2021 at 10:57 PM Bough Chen wrote: Hi Fabio, Force clock on did help us fix some issue, like voltage switch for UHS card. According to your commit log, seems this patch affect the booting time, do you mean the API readx_poll_timeout() cost a lot time? Can you show us the detail info about booting time effected by this patch? If I revert the patch SPL/U-Boot boot in one second. With this patch, it takes around 20 seconds, which is unacceptable. Do you have a chance to see where it consumes so much time? Thanks, Peng. Thanks
Re: [PATCH V3] MAINTAINER, git-mailrc: Update the mmc maintainer
On 2021/6/15 6:16, Jaehoon Chung wrote: Update to me as co-maintainer with Peng. Additionally, update the mmc alias in git-mailrc. Signed-off-by: Jaehoon Chung Reviewed-by: Bin Meng Acked-by: Peng Fan --- Changelog on V2 - keep original alias Changelog on V3 - Update commit-msg - Add Bin's reviewed-by tag --- MAINTAINERS| 1 + doc/git-mailrc | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 86ff5e04a62b..a9257cde4df2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -882,6 +882,7 @@ F: arch/mips/dts/mrvl,cn73xx.dtsi MMC M:Peng Fan +M: Jaehoon Chung S:Maintained T:git https://source.denx.de/u-boot/custodians/u-boot-mmc.git F:drivers/mmc/ diff --git a/doc/git-mailrc b/doc/git-mailrc index 34f936f4d83c..dc7b39b32faf 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -119,7 +119,7 @@ alias kerneldoc uboot, marex alias fdtuboot, sjg alias i2cuboot, hs alias kconfiguboot, masahiro -alias mmcuboot, freenix +alias mmcuboot, freenix, jaehoon alias nand uboot alias netuboot, jhersh alias phyuboot, jhersh
[PATCH] ARM: renesas: Mallocate bootparams on Gen3
The bootparams do not have to be at fixed location, they can be
dynamically mallocated instead. Make it so to get rid of another
fixed assignment.
Signed-off-by: Marek Vasut
Cc: Biju Das
Cc: Lad Prabhakar
---
board/renesas/condor/condor.c | 3 ---
board/renesas/draak/draak.c | 3 ---
board/renesas/eagle/eagle.c | 3 ---
board/renesas/ebisu/ebisu.c | 3 ---
board/renesas/salvator-x/salvator-x.c | 3 ---
board/renesas/ulcb/ulcb.c | 3 ---
include/configs/rcar-gen3-common.h| 2 ++
7 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/board/renesas/condor/condor.c b/board/renesas/condor/condor.c
index e930de31b2..2dd2c1534c 100644
--- a/board/renesas/condor/condor.c
+++ b/board/renesas/condor/condor.c
@@ -21,9 +21,6 @@ DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
{
- /* adress of boot parameters */
- gd->bd->bi_boot_params = CONFIG_SYS_TEXT_BASE + 0x5;
-
return 0;
}
diff --git a/board/renesas/draak/draak.c b/board/renesas/draak/draak.c
index 1d76f95aed..395825f6dc 100644
--- a/board/renesas/draak/draak.c
+++ b/board/renesas/draak/draak.c
@@ -54,9 +54,6 @@ int board_early_init_f(void)
int board_init(void)
{
- /* adress of boot parameters */
- gd->bd->bi_boot_params = CONFIG_SYS_TEXT_BASE + 0x5;
-
/* USB1 pull-up */
setbits_le32(PFC_PUEN6, PUEN_USB1_OVC | PUEN_USB1_PWEN);
diff --git a/board/renesas/eagle/eagle.c b/board/renesas/eagle/eagle.c
index bb32e3d2c5..3417b50f3b 100644
--- a/board/renesas/eagle/eagle.c
+++ b/board/renesas/eagle/eagle.c
@@ -65,9 +65,6 @@ int board_early_init_f(void)
int board_init(void)
{
- /* adress of boot parameters */
- gd->bd->bi_boot_params = CONFIG_SYS_TEXT_BASE + 0x5;
-
return 0;
}
diff --git a/board/renesas/ebisu/ebisu.c b/board/renesas/ebisu/ebisu.c
index 9d4af8d3a6..9a70192596 100644
--- a/board/renesas/ebisu/ebisu.c
+++ b/board/renesas/ebisu/ebisu.c
@@ -32,9 +32,6 @@ DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
{
- /* adress of boot parameters */
- gd->bd->bi_boot_params = CONFIG_SYS_TEXT_BASE + 0x5;
-
return 0;
}
diff --git a/board/renesas/salvator-x/salvator-x.c
b/board/renesas/salvator-x/salvator-x.c
index 071076a336..e4592cafec 100644
--- a/board/renesas/salvator-x/salvator-x.c
+++ b/board/renesas/salvator-x/salvator-x.c
@@ -53,9 +53,6 @@ int board_early_init_f(void)
int board_init(void)
{
- /* adress of boot parameters */
- gd->bd->bi_boot_params = CONFIG_SYS_TEXT_BASE + 0x5;
-
/* USB1 pull-up */
setbits_le32(PFC_PUEN6, PUEN_USB1_OVC | PUEN_USB1_PWEN);
diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
index 7ba1948659..b9431c0c57 100644
--- a/board/renesas/ulcb/ulcb.c
+++ b/board/renesas/ulcb/ulcb.c
@@ -51,9 +51,6 @@ int board_early_init_f(void)
int board_init(void)
{
- /* adress of boot parameters */
- gd->bd->bi_boot_params = CONFIG_SYS_TEXT_BASE + 0x5;
-
/* USB1 pull-up */
setbits_le32(PFC_PUEN6, PUEN_USB1_OVC | PUEN_USB1_PWEN);
diff --git a/include/configs/rcar-gen3-common.h
b/include/configs/rcar-gen3-common.h
index b9762f5beb..99ef27bccd 100644
--- a/include/configs/rcar-gen3-common.h
+++ b/include/configs/rcar-gen3-common.h
@@ -17,6 +17,8 @@
#define CONFIG_SPL_TARGET "spl/u-boot-spl.scif"
#endif
+#define CONFIG_SYS_BOOTPARAMS_LEN SZ_128K
+
/* boot option */
#define CONFIG_CMDLINE_TAG
--
2.30.2
[PATCH] ARM: renesas: Turn on PIE for Gen3
Turn on PIE, so that the U-Boot binary can be started from any arbitrary location in DRAM instead of a predefined fixed one. Note that this patch is not setting SYS_TEXT_BASE=0x0 yet, since that triggers relocation bugs in env code that are yet to be fixed. Signed-off-by: Marek Vasut Cc: Biju Das Cc: Lad Prabhakar --- arch/arm/mach-rmobile/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rmobile/Kconfig b/arch/arm/mach-rmobile/Kconfig index 41322b2c4c..69e40cf382 100644 --- a/arch/arm/mach-rmobile/Kconfig +++ b/arch/arm/mach-rmobile/Kconfig @@ -17,6 +17,7 @@ config RCAR_GEN3 select PINCTRL select PINCONF select PINCTRL_PFC + select POSITION_INDEPENDENT select SUPPORT_SPL imply CMD_FS_UUID imply CMD_GPT -- 2.30.2
[PATCH V3] MAINTAINER, git-mailrc: Update the mmc maintainer
Update to me as co-maintainer with Peng. Additionally, update the mmc alias in git-mailrc. Signed-off-by: Jaehoon Chung Reviewed-by: Bin Meng --- Changelog on V2 - keep original alias Changelog on V3 - Update commit-msg - Add Bin's reviewed-by tag --- MAINTAINERS| 1 + doc/git-mailrc | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 86ff5e04a62b..a9257cde4df2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -882,6 +882,7 @@ F: arch/mips/dts/mrvl,cn73xx.dtsi MMC M: Peng Fan +M: Jaehoon Chung S: Maintained T: git https://source.denx.de/u-boot/custodians/u-boot-mmc.git F: drivers/mmc/ diff --git a/doc/git-mailrc b/doc/git-mailrc index 34f936f4d83c..dc7b39b32faf 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -119,7 +119,7 @@ alias kerneldoc uboot, marex alias fdtuboot, sjg alias i2cuboot, hs alias kconfiguboot, masahiro -alias mmcuboot, freenix +alias mmcuboot, freenix, jaehoon alias nand uboot alias netuboot, jhersh alias phyuboot, jhersh -- 2.29.0
Re: [PATCH V2] MAINTAINER, git-mailrc: Update the mmc maintainer
On 6/14/21 6:35 PM, Bin Meng wrote: > On Mon, Jun 14, 2021 at 1:45 PM Jaehoon Chung wrote: >> >> Update to me as co-maintainer with Peng. >> Additionally, fix the alias in git-mailrc. > > nits: technically it's not "fix" but "update" the mmc alias Sorry. When i had updated to V2, I forgot change commit-msg. Will resend wit your reviewed-by tag. Best Regards, Jaehoon Chung > >> >> Signed-off-by: Jaehoon Chung >> --- >> Changelog on V2 >> - Keep original alias >> --- >> MAINTAINERS| 1 + >> doc/git-mailrc | 2 +- >> 2 files changed, 2 insertions(+), 1 deletion(-) >> > > Otherwise, > > Reviewed-by: Bin Meng >
Re: [PATCH] net: use the same alias stem for ethernet as linux
On Thu, Apr 29, 2021 at 7:10 PM Simon Glass wrote:
>
> On Thu, 25 Feb 2021 at 07:51, Michael Walle wrote:
> >
> > Linux uses the prefix "ethernet" whereas u-boot uses "eth". This is from
> > the linux tree:
> >
> > $ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> > 0
> > $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> > 633
> >
> > In u-boot device trees both prefixes are used. Until recently the only
> > user of the ethernet alias was the sandbox test device tree. This
> > changed with commit fc054d563bfb ("net: Introduce DSA class for Ethernet
> > switches"). There, the MAC addresses are inherited based on the devices
> > sequence IDs which is in turn given by the device tree.
> >
> > Before there are more users in u-boot and both worlds will differ even
> > more, rename the alias prefix to "ethernet" to match the linux ones.
> > Also adapt the test cases and rename any old aliases in the u-boot
> > device trees.
> >
> > Cc: David Wu
> > Signed-off-by: Michael Walle
> > ---
> > Vladimir, I didn't do another patch to rename any ethernet aliases to
> > "eth". Though kontron boards contain "ethernetN" aliases, all in tree
> > variants don't make use of it. So there is nothing to be fixed.
> >
> > arch/arm/dts/fsl-ls1028a-rdb.dts | 12 ++--
> > arch/sandbox/dts/test.dts| 10 +-
> > net/eth-uclass.c | 4 ++--
> > test/dm/ofnode.c | 2 +-
> > test/dm/test-fdt.c | 2 +-
> > 5 files changed, 15 insertions(+), 15 deletions(-)
>
> Reviewed-by: Simon Glass
Applied to u-boot-net/master, thanks!
Best regards,
Ramon Fried
Re: [PATCH] net: use a more deterministic approach to get the active ethernet device
On Thu, Apr 29, 2021 at 11:03 PM Ramon Fried wrote:
>
> On Wed, Feb 24, 2021 at 6:30 PM Michael Walle wrote:
> >
> > If the environment variable "ethact" is not set, the first device in the
> > uclass is returned. This depends on the probing order of the ethernet
> > devices. Moreover it is not not configurable at all.
> >
> > Try to return the ethernet device with sequence id 0 first which then
> > can be configured by the aliases in a device tree. Fall back to the old
> > mechanism in case of an error.
> >
> > Signed-off-by: Michael Walle
> > ---
> > net/eth-uclass.c | 17 -
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> > index 34ca731d1e..0b4260dc5b 100644
> > --- a/net/eth-uclass.c
> > +++ b/net/eth-uclass.c
> > @@ -69,8 +69,11 @@ void eth_set_current_to_next(void)
> > /*
> > * Typically this will simply return the active device.
> > * In the case where the most recent active device was unset, this will
> > attempt
> > - * to return the first device. If that device doesn't exist or fails to
> > probe,
> > - * this function will return NULL.
> > + * to return the device with sequence id 0 (which can be configured by the
> > + * device tree). If this fails, fall back to just getting the first device.
> > + * The latter is non-deterministic and depends on the order of the probing.
> > + * If that device doesn't exist or fails to probe, this function will
> > return
> > + * NULL.
> > */
> > struct udevice *eth_get_dev(void)
> > {
> > @@ -80,9 +83,13 @@ struct udevice *eth_get_dev(void)
> > if (!uc_priv)
> > return NULL;
> >
> > - if (!uc_priv->current)
> > - eth_errno = uclass_first_device(UCLASS_ETH,
> > - _priv->current);
> > + if (!uc_priv->current) {
> > + eth_errno = uclass_get_device_by_seq(UCLASS_ETH, 0,
> > +_priv->current);
> > + if (eth_errno)
> > + eth_errno = uclass_first_device(UCLASS_ETH,
> > + _priv->current);
> > + }
> > return uc_priv->current;
> > }
> >
> > --
> > 2.20.1
> >
> Reviewed-by: Ramon Fried
Applied to u-boot-net/master, thanks!
Best regards,
Ramon Fried
Re: [PATCH v2 1/3] tools: docker: Install a readable kernel for libguestfs-tools
On 6/13/21 4:07 PM, Alper Nebi Yasak wrote: The filesystem and EFI (capsule and secure boot) test setups try to use guestmount and virt-make-fs respectively to prepare disk images to run tests on. However, these libguestfs tools need a kernel image and fail with the following message (revealed in debug/trace mode) if it can't find one: supermin: failed to find a suitable kernel (host_cpu=x86_64). I looked for kernels in /boot and modules in /lib/modules. If this is a Xen guest, and you only have Xen domU kernels installed, try installing a fullvirt kernel (only for supermin use, you shouldn't boot the Xen guest with it). This failure then causes these tests to be skipped in CIs. Install a kernel package in the Docker containers so the CIs can run these tests with libguestfs tools again (assuming the container is run with necessary host devices and privileges). As this kernel would be only used for virtualization, we can use the kernel package specialized for that. On Ubuntu systems kernel images are not readable by non-root users, so explicitly add read permissions with chmod as well. Signed-off-by: Alper Nebi Yasak Acked-by: Heinrich Schuchardt --- Changes in v2: - Add tag "Acked-by: Heinrich Schuchardt " tools/docker/Dockerfile | 4 1 file changed, 4 insertions(+) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index d2f0074ee8a6..563b16639e54 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -71,6 +71,7 @@ RUN apt-get update && apt-get install -y \ libssl-dev \ libudev-dev \ libusb-1.0-0-dev \ + linux-image-kvm \ lzma-alone \ lzop \ mount \ @@ -99,6 +100,9 @@ RUN apt-get update && apt-get install -y \ zip \ && rm -rf /var/lib/apt/lists/* +# Make kernels readable for libguestfs tools to work correctly +RUN chmod +r /boot/vmlinu* /lib/modules/*/vmlinu* || true /lib/modules/4.15.0-1092-kvm# find . -name 'vm*' does not find any file. We don't need '|| true' if you do not refer to non-existent files. Best regards Heinrich + # Manually install libmpfr4 for the toolchains RUN wget http://mirrors.kernel.org/ubuntu/pool/main/m/mpfr4/libmpfr4_3.1.4-1_amd64.deb && dpkg -i libmpfr4_3.1.4-1_amd64.deb && rm libmpfr4_3.1.4-1_amd64.deb
Re: [RESEND PATCH v6 2/2] mmc: openpiton: add piton_mmc driver
Dear Jaehoon,
On 6/14/2021 1:58 PM, Jaehoon Chung wrote:
Hi Tianrui,
On 6/14/21 9:28 AM, Tianrui Wei wrote:
Hi Jaehoon,
Many thanks for taking the time to review our patches :P
On 6/14/2021 6:09 AM, Jaehoon Chung wrote:
Dear Tianrui,
On 6/13/21 2:16 AM, Tianrui Wei wrote:
This commit adds support to piton_mmc driver for OpenPiton-riscv64
In particular, this driver
- V6
. change type of address
. move declarations ahead
. loop style update
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
---
drivers/mmc/Kconfig | 9 +++
drivers/mmc/Makefile | 1 +
drivers/mmc/piton_mmc.c | 169
3 files changed, 179 insertions(+)
create mode 100644 drivers/mmc/piton_mmc.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 8901456967..096d6a930c 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -727,6 +727,15 @@ config MMC_SUNXI_HAS_MODE_SWITCH
bool
depends on MMC_SUNXI
+config MMC_PITON
+ bool "MMC support for OpenPiton SoC"
+ depends on DM_MMC && BLK
+ help
+ This selects support for the SD host controller on
+ OpenPiton SoC. Note that this SD controller directly
+ exposes the contents of the SD card as memory mapped,
+ so there is no manual configuration required
Fix indentation.
Will do
+
config GENERIC_ATMEL_MCI
bool "Atmel Multimedia Card Interface support"
depends on DM_MMC && BLK && ARCH_AT91
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 89d6af3db3..cc08b41d0d 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_MMC_SDHCI_XENON) += xenon_sdhci.o
obj-$(CONFIG_MMC_SDHCI_ZYNQ) += zynq_sdhci.o
obj-$(CONFIG_MMC_SUNXI) += sunxi_mmc.o
+obj-$(CONFIG_MMC_PITON) += piton_mmc.o
Ditto.
obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o
obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o
obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o
diff --git a/drivers/mmc/piton_mmc.c b/drivers/mmc/piton_mmc.c
new file mode 100644
index 00..32671d1a89
--- /dev/null
+++ b/drivers/mmc/piton_mmc.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2009 SAMSUNG Electronics
+ * Minkyu Kang
+ * Jaehoon Chung
+ * Portions Copyright 2011-2019 NVIDIA Corporation
+ * Portions Copyright 2021 Tianrui Wei
+ * This file is adapted from tegra_mmc.c
+ * Tianrui Wei
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct piton_mmc_plat {
+ struct mmc_config cfg;
+ struct mmc mmc;
+};
+
+struct piton_mmc_priv {
+ void __iomem *piton_mmc_base_addr; /* peripheral id */
+};
+
+/*
+ * see mmc_read_blocks to see how it is used.
+ * start block is hidden at cmd->arg
+ * also, initialize the block size at init
+ */
+static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+ struct mmc_data
*data)
Ditto.
Will do
+{
+ /* check first if this is a pure command */
+ if (!data)
+ return 0;
+
+ struct piton_mmc_priv *priv = dev_get_priv(dev);
+ u32 *buff, *start_addr;
+ size_t byte_cnt, start_block;
+
+ buff = (u32 *)data->dest;
+ start_block = cmd->cmdarg;
+ start_addr = priv->piton_mmc_base_addr + start_block;
+
+ /* if there is a read */
+ if (data->flags & MMC_DATA_READ) {
+ for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
+ byte_cnt -= sizeof(u32)) {
+ *buff++ = readl(start_addr++);
+ }
+ } else {
+ return -ENOSYS;
Is is right to return -ENOSYS? MMC_DATA_WRITE doesn't support?
Will change to support it
+ }
+
+ return 0;
+}
+
+static int piton_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+ struct piton_mmc_priv *priv = dev_get_priv(dev);
+ struct piton_mmc_plat *plat = dev_get_platdata(dev);
+ struct mmc_config *cfg;
+ struct mmc *mmc;
+ /* fill in device description */
+ struct blk_desc *bdesc;
+
+ priv->piton_mmc_base_addr = (void *)dev_read_addr(dev);
+ cfg = >cfg;
+ cfg->name = "PITON MMC";
+ cfg->host_caps = MMC_MODE_8BIT;
+ cfg->f_max = 10;
f_max is 100K? I don't think so.
We don't use f_max anywhere, so we're setting dummy values :P
+ cfg->f_min = 40;
+ cfg->voltages = MMC_VDD_21_22;
+
+ mmc = >mmc;
+ mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
+ mmc->capacity_user = 0x1;
+ mmc->capacity_user *= mmc->read_bl_len;
+ mmc->capacity_boot = 0;
+ mmc->capacity_rpmb = 0;
+ for (int i = 0; i < 4; i++)
+ mmc->capacity_gp[i] = 0;
+ mmc->capacity = 0x20ULL;
Use macro. It's not readable. What's 0x20ULL?
Will do
+ mmc->has_init = 1;
Right? has_init will be set in mmc.c.
Why it's set to 1 in driver?
Our
[PATCH v7 2/2] mmc: openpiton: add piton_mmc driver
This commit adds support to piton_mmc driver for OpenPiton-riscv64
In particular, this driver
- V6
. change type of address
. move declarations ahead
. loop style update
- V7
. dm updates
. fix indentations
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
---
drivers/mmc/Kconfig | 9 ++
drivers/mmc/Makefile| 1 +
drivers/mmc/piton_mmc.c | 181
3 files changed, 191 insertions(+)
create mode 100644 drivers/mmc/piton_mmc.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 8901456967..4948e194e7 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -727,6 +727,15 @@ config MMC_SUNXI_HAS_MODE_SWITCH
bool
depends on MMC_SUNXI
+config MMC_PITON
+ bool "MMC support for OpenPiton SoC"
+ depends on DM_MMC && BLK
+ help
+ This selects support for the SD host controller on OpenPiton SoC.
+ Note that this SD controller directly exposes the contents of the
+ SD card as memory mapped, so there is no manual configuration
+ required
+
config GENERIC_ATMEL_MCI
bool "Atmel Multimedia Card Interface support"
depends on DM_MMC && BLK && ARCH_AT91
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 89d6af3db3..d96ac90719 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_MMC_SDHCI_XENON) += xenon_sdhci.o
obj-$(CONFIG_MMC_SDHCI_ZYNQ) += zynq_sdhci.o
obj-$(CONFIG_MMC_SUNXI)+= sunxi_mmc.o
+obj-$(CONFIG_MMC_PITON)+= piton_mmc.o
obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o
obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o
obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o
diff --git a/drivers/mmc/piton_mmc.c b/drivers/mmc/piton_mmc.c
new file mode 100644
index 00..8517ec8410
--- /dev/null
+++ b/drivers/mmc/piton_mmc.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2009 SAMSUNG Electronics
+ * Minkyu Kang
+ * Jaehoon Chung
+ * Portions Copyright 2011-2019 NVIDIA Corporation
+ * Portions Copyright 2021 Tianrui Wei
+ * This file is adapted from tegra_mmc.c
+ * Tianrui Wei
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define PITON_MMC_DUMMY_F_MAX 2000
+#define PITON_MMC_DUMMY_F_MIN 1000
+#define PITON_MMC_DUMMY_CAPACITY SZ_4G << 3
+#define PITON_MMC_DUMMY_B_MAX SZ_4G
+
+struct piton_mmc_plat {
+ struct mmc_config cfg;
+ struct mmc mmc;
+};
+
+struct piton_mmc_priv {
+ void __iomem *piton_mmc_base_addr; /* peripheral id */
+};
+
+/*
+ * see mmc_read_blocks to see how it is used.
+ * start block is hidden at cmd->arg
+ * also, initialize the block size at init
+ */
+static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
+ /* check first if this is a pure command */
+ if (!data)
+ return 0;
+
+ struct piton_mmc_priv *priv = dev_get_priv(dev);
+ u32 *buff, *start_addr, *write_src;
+ size_t byte_cnt, start_block;
+
+ buff = (u32 *)data->dest;
+ write_src = (u32 *)data->src;
+ start_block = cmd->cmdarg;
+ start_addr = priv->piton_mmc_base_addr + start_block;
+
+ /* if there is a read */
+ if (data->flags & MMC_DATA_READ) {
+ for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
+byte_cnt -= sizeof(u32)) {
+ *buff++ = readl(start_addr++);
+ }
+ } else {
+ for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
+byte_cnt -= sizeof(u32)) {
+ writel(*write_src++,start_addr++);
+ }
+
+ }
+
+ return 0;
+}
+
+static int piton_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+ struct piton_mmc_priv *priv = dev_get_priv(dev);
+ struct piton_mmc_plat *plat = dev_get_plat(dev);
+ struct mmc_config *cfg;
+ struct mmc *mmc;
+ /* fill in device description */
+ struct blk_desc *bdesc;
+
+ priv->piton_mmc_base_addr = (void *)dev_read_addr(dev);
+ cfg = >cfg;
+ cfg->name = "PITON MMC";
+ cfg->host_caps = MMC_MODE_8BIT;
+ cfg->f_max = PITON_MMC_DUMMY_F_MAX;
+ cfg->f_min = PITON_MMC_DUMMY_F_MIN;
+ cfg->voltages = MMC_VDD_21_22;
+
+ mmc = >mmc;
+ mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
+ mmc->capacity_user = PITON_MMC_DUMMY_CAPACITY;
+ mmc->capacity_user *= mmc->read_bl_len;
+ mmc->capacity_boot = 0;
+ mmc->capacity_rpmb = 0;
+ for (int i = 0; i < 4; i++)
+ mmc->capacity_gp[i] = 0;
+ mmc->capacity = PITON_MMC_DUMMY_CAPACITY;
+
[PATCH v7 1/2] board: riscv: add openpiton-riscv64 SoC support
This patch adds openpiton-riscv64 SOC support. In particular, this
board supports a standard bootflow through zsbl->u-boot SPL->
opensbi->u-boot proper->Linux. There are separate defconfigs for
building u-boot SPL and u-boot proper
- V6
. separate defconfigs for u-boot and SPL
. eliminate debug console output
. style updates
- V7
. update Kconfig for OpenPiton board
. SPL defconfig update
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
---
arch/riscv/Kconfig | 4 +
arch/riscv/dts/Makefile | 1 +
arch/riscv/dts/openpiton-riscv64.dts| 153
board/openpiton/riscv64/Kconfig | 40 +++
board/openpiton/riscv64/MAINTAINERS | 8 +
board/openpiton/riscv64/Makefile| 5 +
board/openpiton/riscv64/openpiton-riscv64.c | 33 ++
configs/openpiton_riscv64_defconfig | 76
configs/openpiton_riscv64_spl_defconfig | 87 +
doc/board/index.rst | 1 +
doc/board/openpiton/index.rst | 9 +
doc/board/openpiton/riscv64.rst | 376
include/configs/openpiton-riscv64.h | 61
13 files changed, 854 insertions(+)
create mode 100644 arch/riscv/dts/openpiton-riscv64.dts
create mode 100644 board/openpiton/riscv64/Kconfig
create mode 100644 board/openpiton/riscv64/MAINTAINERS
create mode 100644 board/openpiton/riscv64/Makefile
create mode 100644 board/openpiton/riscv64/openpiton-riscv64.c
create mode 100644 configs/openpiton_riscv64_defconfig
create mode 100644 configs/openpiton_riscv64_spl_defconfig
create mode 100644 doc/board/openpiton/index.rst
create mode 100644 doc/board/openpiton/riscv64.rst
create mode 100644 include/configs/openpiton-riscv64.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index b3d7fd84ce..4b0c3dffa6 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -26,6 +26,9 @@ config TARGET_SIFIVE_UNMATCHED
config TARGET_SIPEED_MAIX
bool "Support Sipeed Maix Board"
+config TARGET_OPENPITON_RISCV64
+ bool "Support RISC-V cores on OpenPiton SoC"
+
endchoice
config SYS_ICACHE_OFF
@@ -60,6 +63,7 @@ source "board/emulation/qemu-riscv/Kconfig"
source "board/microchip/mpfs_icicle/Kconfig"
source "board/sifive/unleashed/Kconfig"
source "board/sifive/unmatched/Kconfig"
+source "board/openpiton/riscv64/Kconfig"
source "board/sipeed/maix/Kconfig"
# platform-specific options below
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 7778874831..b6e9166767 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -3,6 +3,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
diff --git a/arch/riscv/dts/openpiton-riscv64.dts
b/arch/riscv/dts/openpiton-riscv64.dts
new file mode 100644
index 00..45951e1236
--- /dev/null
+++ b/arch/riscv/dts/openpiton-riscv64.dts
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2021 Tianrui Wei */
+
+/*
+ * This dts is for a dual core instance of OpenPiton+Ariane built
+ * to run on a Digilent Genesys 2 FPGA at 66.67MHz. These files
+ * are automatically generated by the OpenPiton build system and
+ * this configuration may not be what you need if your configuration
+ * is different from the below.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "openpiton,riscv64";
+
+ chosen {
+ stdout-path = "uart0:115200";
+ };
+
+ aliases {
+ console =
+ serial0 =
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <520835>;
+
+ CPU0: cpu@0 {
+ clocks = <>;
+ u-boot,dm-spl;
+ device_type = "cpu";
+ reg = <0>;
+ compatible = "openhwgroup,cva6", "riscv";
+ riscv,isa = "rv64imafdc";
+ mmu-type = "riscv,sv39";
+ tlb-split;
+ // HLIC - hart local interrupt controller
+ CPU0_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ };
+ };
+
+ CPU1: cpu@1 {
+ clocks = <>;
+ device_type = "cpu";
+ reg = <1>;
+
[PATCH v7 0/2] Add OpenPiton-riscv64 board support
This patch set is to add OpenPiton board support. Patches are split into several parts: - [PATCH 1/2] add OpenPiton support to mmc driver - [PATCH 2/2] add support for OpenPiton board Description - for mmc driver, it's settings are automatically configured at hardware level. We only need to expose the memory mapped interface through U-Boot driver model - For OpenPiton, as we need to embed the device tree blob into the bitstream, there is currently no itb support Tests checks - Able to boot Debian Linux from SD card on Digilent Genesys 2 - Checkpatch is performed, with some warnings ignored Changelogs - V2 . fix styles and typos in [1/2] and [2/2] . add board documentation in [2/2] - V3 . fix styles in [1/2] - V4 . fix checkpatch warnings in [1/2] except MAINTAINERS - V5 . major changes in device tree . changed to OF_SEPARATE . formatting update for mmc - V6 . eliminate debug outputs altogether . separate defconfigs between SPL and u-boot proper . style updates thanks to Sean - V7 . mmc dm fixes . mmc style updates, improving readibility . mmc add write support . OpenPiton RISC-V 64 board Kconfig fixes Acknowledgements We'd like to thank all maintainers who have reviewed our code. But we'd like to thank Sean and Jaehoon in particular for taking much time and energy to help us write better code. Tianrui Wei (2): board: riscv: add openpiton-riscv64 SoC support mmc: openpiton: add piton_mmc driver arch/riscv/Kconfig | 4 + arch/riscv/dts/Makefile | 1 + arch/riscv/dts/openpiton-riscv64.dts| 153 board/openpiton/riscv64/Kconfig | 40 +++ board/openpiton/riscv64/MAINTAINERS | 8 + board/openpiton/riscv64/Makefile| 5 + board/openpiton/riscv64/openpiton-riscv64.c | 33 ++ configs/openpiton_riscv64_defconfig | 76 configs/openpiton_riscv64_spl_defconfig | 87 + doc/board/index.rst | 1 + doc/board/openpiton/index.rst | 9 + doc/board/openpiton/riscv64.rst | 376 drivers/mmc/Kconfig | 9 + drivers/mmc/Makefile| 1 + drivers/mmc/piton_mmc.c | 181 ++ include/configs/openpiton-riscv64.h | 61 16 files changed, 1045 insertions(+) create mode 100644 arch/riscv/dts/openpiton-riscv64.dts create mode 100644 board/openpiton/riscv64/Kconfig create mode 100644 board/openpiton/riscv64/MAINTAINERS create mode 100644 board/openpiton/riscv64/Makefile create mode 100644 board/openpiton/riscv64/openpiton-riscv64.c create mode 100644 configs/openpiton_riscv64_defconfig create mode 100644 configs/openpiton_riscv64_spl_defconfig create mode 100644 doc/board/openpiton/index.rst create mode 100644 doc/board/openpiton/riscv64.rst create mode 100644 drivers/mmc/piton_mmc.c create mode 100644 include/configs/openpiton-riscv64.h -- 2.32.0
Re: [PATCH v2] cmd: net: add a 'net list' command to list network devs
On Mon, Jun 14, 2021 at 6:36 PM Tim Harvey wrote: > > On Sat, Jun 12, 2021 at 12:02 PM Ramon Fried wrote: > > > > Hi Tim. > > The patch fails build in several boards (Malta variants): > > > > +cmd/net.c: In function 'do_net_list': > > 42+cmd/net.c:487:34: error: initialization of 'const struct udevice *' > > from incompatible pointer type 'struct eth_device *' > > [-Werror=incompatible-pointer-types] > > 43+ 487 | const struct udevice *current = eth_get_dev(); > > 44+ | ^~~ > > > > Ramon, > > Looks like my patch only works for DM_ETH. If I were to implement this > for legacy eth it would probably be a mess as the device list is a > static struct in net/eth_legacy.c. I'm not sure how to tell how many > boards are out there that are not yet converted to DM_ETH and am not > sure when legacy eth goes away. How about if I just add #ifdef > CONFIG_DM_ETH around the whole thing and it isn't supported for legacy > eth? > > Best Regards, > > Tim Sounds good to me.
[PATCH] lib: remove superfluous #ifdefs from date.c
We should avoid #ifdef in C modules. Unused functions are eliminated by the linker. Signed-off-by: Heinrich Schuchardt --- lib/date.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/lib/date.c b/lib/date.c index 0456de78ab..c589d9ed3a 100644 --- a/lib/date.c +++ b/lib/date.c @@ -10,8 +10,6 @@ #include #include -#if defined(CONFIG_LIB_DATE) || defined(CONFIG_TIMESTAMP) - #define FEBRUARY 2 #defineSTARTOFTIME 1970 #define SECDAY 86400L @@ -97,9 +95,6 @@ unsigned long rtc_mktime(const struct rtc_time *tm) return (hours * 60 + tm->tm_min) * 60 + tm->tm_sec; } -#endif /* CONFIG_LIB_DATE || CONFIG_TIMESTAMP */ - -#ifdef CONFIG_LIB_DATE /* for compatibility with linux code */ time64_t mktime64(const unsigned int year, const unsigned int mon, const unsigned int day, const unsigned int hour, @@ -116,4 +111,3 @@ time64_t mktime64(const unsigned int year, const unsigned int mon, return (time64_t)rtc_mktime((const struct rtc_time *)); } -#endif -- 2.30.2
Re: [PATCH v2] cmd: net: add a 'net list' command to list network devs
On Sat, Jun 12, 2021 at 12:02 PM Ramon Fried wrote: > > Hi Tim. > The patch fails build in several boards (Malta variants): > > +cmd/net.c: In function 'do_net_list': > 42+cmd/net.c:487:34: error: initialization of 'const struct udevice *' > from incompatible pointer type 'struct eth_device *' > [-Werror=incompatible-pointer-types] > 43+ 487 | const struct udevice *current = eth_get_dev(); > 44+ | ^~~ > Ramon, Looks like my patch only works for DM_ETH. If I were to implement this for legacy eth it would probably be a mess as the device list is a static struct in net/eth_legacy.c. I'm not sure how to tell how many boards are out there that are not yet converted to DM_ETH and am not sure when legacy eth goes away. How about if I just add #ifdef CONFIG_DM_ETH around the whole thing and it isn't supported for legacy eth? Best Regards, Tim
Re: [PATCH v2] Revert "mmc: fsl_esdhc_imx: use VENDORSPEC_FRC_SDCLK_ON to control card clock output"
Hi Bough, On Wed, Jun 9, 2021 at 7:44 AM Bough Chen wrote: > Give me a few days, I'm busy these days, will do when I have time. We are already in 2021.04-rc4, so I think it is safer to go with the revert for now and then you provide a proper fix later. imx7s-warp is also affected by this.
Re: [PATCH] efi_loader: FMP cleanups
Too fast on the trigger.
The efi_load_capsule_drivers() must go into an IS_ENABLED. I'll wait
for any other comments and send a V2
On Mon, 14 Jun 2021 at 18:10, Ilias Apalodimas
wrote:
>
> Right now we allow both of the FMPs (RAW and FIT based) to be installed at
> the same time. Moreover we only install those if a CapsuleUpdate is
> requested. Since we now have an ESRT table, it makes more sense to
> unconditionally install the FMP, so any userspace applications (e.g fwupd)
> can make use of them and trigger an update.
>
> While at it clean up the FMP installation as well. Chapter 23 of the EFI
> spec (rev 2.9) says:
> "A specific updatable hardware firmware store must be represented by
> exactly one FMP instance".
> This is not the case for us, since both of our FMP protocols can be
> installed at the same time and are controlled by a single 'dfu_alt_info'
> env variable.
> So make the config option a choice and allow the user to install one
> of them at any given time.
>
> The overall changes show up in fwupd
>
> pre-patch:
> fwupdmgr get-devices
> No detected devices
>
> post-patch (with FIT FMP installed):
> fwupdmgr get-devices
> WARNING: Required efivarfs filesystem was not found
> See https://github.com/fwupd/fwupd/wiki/PluginFlag:efivar-not-mounted for
> more information.
> Unknown Product
> │
> └─Unknown Firmware:
> Device ID: 605080e08f71dabb86d0781c28f7d923edabf7d6
> Current version:0
> Vendor: DMI:U-Boot
> Update Error: Not updatable as efivarfs was not found
> GUIDs: ae13ff2d-9ad4-4e25-9ac8-6d80b3b22147
> 230c8b18-8d9b-53ec-838b-6cfc0383493a ←
> main-system-firmware
> 1a1da7d4-0a24-51b5-8a1a-1e3274328094 ←
> UEFI\RES_{AE13FF2D-9AD4-4E25-9AC8-6D80B3B22147}
> Device Flags: • Internal device
> • System requires external power source
> • Needs a reboot after installation
> • Device is usable for the duration of the update
>
> Signed-off-by: Ilias Apalodimas
> ---
> configs/sandbox64_defconfig | 1 -
> configs/sandbox_defconfig| 1 -
> configs/xilinx_zynqmp_virt_defconfig | 1 -
> include/efi_loader.h | 1 +
> lib/efi_loader/Kconfig | 48 +++-
> lib/efi_loader/efi_capsule.c | 22 -
> lib/efi_loader/efi_setup.c | 4 +++
> 7 files changed, 37 insertions(+), 41 deletions(-)
>
> diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
> index 9a373bab6fe3..af18b6c7826e 100644
> --- a/configs/sandbox64_defconfig
> +++ b/configs/sandbox64_defconfig
> @@ -233,7 +233,6 @@ CONFIG_LZ4=y
> CONFIG_ERRNO_STR=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> CONFIG_EFI_SECURE_BOOT=y
> CONFIG_TEST_FDTDEC=y
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index bdbf714e2bd9..24313fdfa53d 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -280,7 +280,6 @@ CONFIG_LZ4=y
> CONFIG_ERRNO_STR=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> CONFIG_EFI_SECURE_BOOT=y
> CONFIG_TEST_FDTDEC=y
> diff --git a/configs/xilinx_zynqmp_virt_defconfig
> b/configs/xilinx_zynqmp_virt_defconfig
> index e939b04ef6a5..0c2d1a70a5a1 100644
> --- a/configs/xilinx_zynqmp_virt_defconfig
> +++ b/configs/xilinx_zynqmp_virt_defconfig
> @@ -188,5 +188,4 @@ CONFIG_EFI_SET_TIME=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 0a9c82a257e1..b81180cfda8b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -972,4 +972,5 @@ efi_status_t efi_esrt_register(void);
> * - error code otherwise.
> */
> efi_status_t efi_esrt_populate(void);
> +efi_status_t efi_load_capsule_drivers(void);
> #endif /* _EFI_LOADER_H */
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 6242caceb7f9..da6f5faf5adb 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -161,6 +161,31 @@ config EFI_CAPSULE_FIRMWARE_MANAGEMENT
> Select this option if you want to enable capsule-based
> firmware update using Firmware Management Protocol.
>
> +choice EFI_CAPSULE_TYPE
> + prompt "Capsule type (RAW/FIT)"
> + depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
> +
> +config EFI_CAPSULE_FIRMWARE_FIT
> + bool "FMP driver for FIT images"
> + depends on FIT
> + select UPDATE_FIT
> + select DFU
> + select EFI_CAPSULE_FIRMWARE
> + help
> + Select this option if you want
Announcing a tool for Armada 3720 firmware
Hello, this is announcement of mox-imager [1], a firmware uploader / manipulator for Marvell's Armada 3720 SOC. For most of you who use the SOC on boards other than Turris MOX, the most useful feature probably is that it can upload a firmware via UART at higher baudrates than Marvell's original WtpDownloader, which is useful when debugging or during board manufacture. Features that should be interesting for you: - ability to upload firmware over UART at baudrates up to 6 MBaud. This was tested on ESPRESSObin, but should also work on other boards (uDPU, ESPRESSObin Ultra) Uploading at 3 MBaud: $ ./mox-imager -b 300 -D /dev/ttyUSB0 flash-image.bin - ability to upload flash-image.bin firmware over UART When TF-A builds for A3720, it creates image for SPI/eMMC called flash-image.bin, and a directory uart-images containing 3 binaries that you have to use instead of flash-image.bin if you want to boot via UART. mox-imager can work with both methods. When given flash-image.bin, it updates BootFlashSign in the TIM header so that the BootROM will accept the image when given over UART. So both of these work: $ ./mox-imager -D /dev/ttyUSB0 flash-image.bin $ ./mox-imager -D /dev/ttyUSB0 TIM_ATF.bin wtmi_h.bin boot-image_h.bin (This of course does not work if the image needs to be signed cryptographically and the singing key is not present. But AFAIK only Turris MOX uses this feature of the SOC.) - mox-imager has an implementation of a mini-terminal (code from U-Boot's kwboot), which can be used instead of minicom/kermit, once the firmware is uploaded. Although this mini-terminal does not support uploading images over Y-MODEM or other protocols to U-Boot, it can still be useful. If not for anything else, then at least for the ability to not lose any output which the SOC might have sent over UART. (When using minicom/kermit, there is a small window when the /dev/ttyX device is closed and some output is lost.) Use the -t flag to invoke this mini-terminal. Other features that we use on Turris MOX and may be useful to you, but need implementation for your boards: - we use one firmware image for all versions of our board: DDR3 512 MiB, DDR3 1024 MiB, DDR4 This simplifies development of updates significantly. We achieve this by burning board version info into the SOC's OTP. The GPP code contained in the TIM header can read OTP and decide how to initialize clock and DDR registers depending on the values there. The GPP code also works when OTP is empty. In that case it first tries to initialize the registers for DDR3, tests if DDR works, and if not, switches to DDR4. Then it determines RAM size. Note that we do not use this method in production, this was only tested on a few boards that we use for development. (We do not know for example, whether it is safe for the DDR4 chip if we first try to communicate with it in DDR3 mode, since the protocols are different.) You can look at the GPP code at https://gitlab.nic.cz/turris/mox-imager/-/blob/master/gpp/ddr.gpp - mox-imager can create trusted firmware image signed with ECDSA signature and can write the SOC's OTP so that only images signed with a specific ECDSA key will boot. We use this on Turris MOX. Related software: - we have significantly modified Marvell's original WTMI firmware that runs on the Cortex-M3 secure coprocessor. You can look at this modified firmware at our mox-boot-builder repository [2] in directory wtmi. Perhaps the most interesting feature for you is that this firmware exposes the SOC's internal HW RNG via the mailbox to Linux, and that upstream Linux has a driver (turris-mox-rwtm) that registers this random number generator via Linux' crypto API. Another feature our firmware supports is that it can utilize the crypto engine in the secure processor for creating ECDSA signatures. Every Turris MOX has an ECDSA key generated and burned into OTP when manufactured. When done correctly, it is impossible to read this key. It is only possible to use it via the crypto engine for ECDSA signatures. (The firmware has to be in trusted mode for this. If the user has the ability to upload any firmware into their device, they can read the private key from OTP.) This firmware can be built as a standalone replacement of Marvell's WTMI firmware from A3700-utils-marvell repository, but also as an wtmi_app.bin payload application for Marvell's firmware (in this case DDR and clocks are initialized by Marvell's code and HW RNG is provided by wtmi_app.bin). There are instructions on how to use this firmware on ESPRESSObin in mox-boot-builder's README.md. - turris-mox-rwtm driver in Linux [3] communicates with our WTMI firmware (see the point above) and exposes to Linux: - the SOC's HWRNG - the SOC's ECDSA signing engine with singing key stored in OTP. This can be used for authorizing the device, for example via SSH
Re: [PATCH v9 00/28] mtd: spi-nor-core: add xSPI Octal DTR support
Jagan, On 26/05/21 10:35PM, Jagan Teki wrote: > On Mon, May 10, 2021 at 6:50 PM Pratyush Yadav wrote: > > > > Jagan, > > > > On 05/05/21 03:11PM, Pratyush Yadav wrote: > > > Hi, > > > > > > This series adds support for octal DTR flashes in the SPI NOR framework, > > > and then adds hooks for the Cypress S28HS512T and Micron MT35XU512ABA > > > flashes. > > > > > > The Cadence QSPI controller driver is also updated to run in Octal DTR > > > mode. > > > > > > Tested on TI J721E for MT35XU512ABA and J7200 for S28HS512T. Also tested > > > on M`T25QU512A for regressions. > > > > Can you please pick this series up as soon as possible? It makes lots of > > changes to the SPI NOR core. Let's cook this in next for a while to > > catch out any issues. This would avoid surprises close to the merge > > window. > > I have a plan to apply this to the next since it crosses the last MW. > can you send the footprint statistics? I can see and then apply next > on my repo to merge early MW. Since Tom opened the next branch [0], can you pick this series up? The more time it gets to spend in next the better. [0] https://lore.kernel.org/u-boot/20210611122915.GS9516@bill-the-cat/ -- Regards, Pratyush Yadav Texas Instruments Inc.
[PATCH] efi_loader: FMP cleanups
Right now we allow both of the FMPs (RAW and FIT based) to be installed at
the same time. Moreover we only install those if a CapsuleUpdate is
requested. Since we now have an ESRT table, it makes more sense to
unconditionally install the FMP, so any userspace applications (e.g fwupd)
can make use of them and trigger an update.
While at it clean up the FMP installation as well. Chapter 23 of the EFI
spec (rev 2.9) says:
"A specific updatable hardware firmware store must be represented by
exactly one FMP instance".
This is not the case for us, since both of our FMP protocols can be
installed at the same time and are controlled by a single 'dfu_alt_info'
env variable.
So make the config option a choice and allow the user to install one
of them at any given time.
The overall changes show up in fwupd
pre-patch:
fwupdmgr get-devices
No detected devices
post-patch (with FIT FMP installed):
fwupdmgr get-devices
WARNING: Required efivarfs filesystem was not found
See https://github.com/fwupd/fwupd/wiki/PluginFlag:efivar-not-mounted for
more information.
Unknown Product
│
└─Unknown Firmware:
Device ID: 605080e08f71dabb86d0781c28f7d923edabf7d6
Current version:0
Vendor: DMI:U-Boot
Update Error: Not updatable as efivarfs was not found
GUIDs: ae13ff2d-9ad4-4e25-9ac8-6d80b3b22147
230c8b18-8d9b-53ec-838b-6cfc0383493a ←
main-system-firmware
1a1da7d4-0a24-51b5-8a1a-1e3274328094 ←
UEFI\RES_{AE13FF2D-9AD4-4E25-9AC8-6D80B3B22147}
Device Flags: • Internal device
• System requires external power source
• Needs a reboot after installation
• Device is usable for the duration of the update
Signed-off-by: Ilias Apalodimas
---
configs/sandbox64_defconfig | 1 -
configs/sandbox_defconfig| 1 -
configs/xilinx_zynqmp_virt_defconfig | 1 -
include/efi_loader.h | 1 +
lib/efi_loader/Kconfig | 48 +++-
lib/efi_loader/efi_capsule.c | 22 -
lib/efi_loader/efi_setup.c | 4 +++
7 files changed, 37 insertions(+), 41 deletions(-)
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 9a373bab6fe3..af18b6c7826e 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -233,7 +233,6 @@ CONFIG_LZ4=y
CONFIG_ERRNO_STR=y
CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
-CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index bdbf714e2bd9..24313fdfa53d 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -280,7 +280,6 @@ CONFIG_LZ4=y
CONFIG_ERRNO_STR=y
CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
-CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
diff --git a/configs/xilinx_zynqmp_virt_defconfig
b/configs/xilinx_zynqmp_virt_defconfig
index e939b04ef6a5..0c2d1a70a5a1 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -188,5 +188,4 @@ CONFIG_EFI_SET_TIME=y
CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y
-CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 0a9c82a257e1..b81180cfda8b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -972,4 +972,5 @@ efi_status_t efi_esrt_register(void);
* - error code otherwise.
*/
efi_status_t efi_esrt_populate(void);
+efi_status_t efi_load_capsule_drivers(void);
#endif /* _EFI_LOADER_H */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 6242caceb7f9..da6f5faf5adb 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -161,6 +161,31 @@ config EFI_CAPSULE_FIRMWARE_MANAGEMENT
Select this option if you want to enable capsule-based
firmware update using Firmware Management Protocol.
+choice EFI_CAPSULE_TYPE
+ prompt "Capsule type (RAW/FIT)"
+ depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
+
+config EFI_CAPSULE_FIRMWARE_FIT
+ bool "FMP driver for FIT images"
+ depends on FIT
+ select UPDATE_FIT
+ select DFU
+ select EFI_CAPSULE_FIRMWARE
+ help
+ Select this option if you want to enable firmware management protocol
+ driver for FIT image
+
+config EFI_CAPSULE_FIRMWARE_RAW
+ bool "FMP driver for raw images"
+ select DFU_WRITE_ALT
+ select DFU
+ select EFI_CAPSULE_FIRMWARE
+ help
+ Select this option if you want to enable firmware management protocol
+ driver for raw image
+
+endchoice
+
config EFI_CAPSULE_AUTHENTICATE
bool
Re: [PATCH u-boot-marvell] arm: mvebu: turris_{omnia,mox}: ensure running bootcmd_rescue always works
Hi Marek, On 14.06.21 16:49, Marek Behun wrote: Hi Stefan, Pali discovered this issue with the bootcmd_rescue code for Omnia & MOX. The patch is a therefore a fix. Is is still possible to send this for v2021.07 ? Sorry for the inconvenience. No problem. I'll integrate it soon and will send a new pull request. Should be possible. Thanks, Stefan
Re: [PATCH u-boot-marvell] arm: mvebu: turris_{omnia,mox}: ensure running bootcmd_rescue always works
Hi Stefan, Pali discovered this issue with the bootcmd_rescue code for Omnia & MOX. The patch is a therefore a fix. Is is still possible to send this for v2021.07 ? Sorry for the inconvenience. Marek
[PATCH u-boot-marvell] arm: mvebu: turris_{omnia, mox}: ensure running bootcmd_rescue always works
From: Pali Rohár
One of the points of putting the rescue boot command into default
environment is that user can invoke it without physical access to the
board (without having to press the factory reset button), by running
run bootcmd_rescue
in U-Boot's console.
Therefore we have to ensure that bootcmd_rescue is always set to default
value, regardless of whether the factory reset button was pressed.
Otherwise the variable will be empty for example after upgrade from
previous U-Boot.
Fixes: ec3784d62646 ("arm: mvebu: turris_mox: add support for board rescue
mode")
Fixes: 176c3e7760a2 ("arm: mvebu: turris_omnia: support invoking rescue boot
from console")
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
---
board/CZ.NIC/turris_mox/turris_mox.c | 14 +++---
board/CZ.NIC/turris_omnia/turris_omnia.c | 13 ++---
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/board/CZ.NIC/turris_mox/turris_mox.c
b/board/CZ.NIC/turris_mox/turris_mox.c
index 44c272c7cb..428cd23a19 100644
--- a/board/CZ.NIC/turris_mox/turris_mox.c
+++ b/board/CZ.NIC/turris_mox/turris_mox.c
@@ -440,10 +440,18 @@ static bool read_reset_button(void)
static void handle_reset_button(void)
{
+ const char * const vars[1] = { "bootcmd_rescue", };
+
+ /*
+* Ensure that bootcmd_rescue has always stock value, so that running
+* run bootcmd_rescue
+* always works correctly.
+*/
+ env_set_default_vars(1, (char * const *)vars, 0);
+
if (read_reset_button()) {
- const char * const vars[3] = {
+ const char * const vars[2] = {
"bootcmd",
- "bootcmd_rescue",
"distro_bootcmd",
};
@@ -451,7 +459,7 @@ static void handle_reset_button(void)
* Set the above envs to their default values, in case the user
* managed to break them.
*/
- env_set_default_vars(3, (char * const *)vars, 0);
+ env_set_default_vars(2, (char * const *)vars, 0);
/* Ensure bootcmd_rescue is used by distroboot */
env_set("boot_targets", "rescue");
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index ade923f599..8b2f94f959 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -339,9 +339,17 @@ static int set_regdomain(void)
static void handle_reset_button(void)
{
+ const char * const vars[1] = { "bootcmd_rescue", };
int ret;
u8 reset_status;
+ /*
+* Ensure that bootcmd_rescue has always stock value, so that running
+* run bootcmd_rescue
+* always works correctly.
+*/
+ env_set_default_vars(1, (char * const *)vars, 0);
+
ret = omnia_mcu_read(CMD_GET_RESET, _status, 1);
if (ret) {
printf("omnia_mcu_read failed: %i, reset status unknown!\n",
@@ -352,9 +360,8 @@ static void handle_reset_button(void)
env_set_ulong("omnia_reset", reset_status);
if (reset_status) {
- const char * const vars[3] = {
+ const char * const vars[2] = {
"bootcmd",
- "bootcmd_rescue",
"distro_bootcmd",
};
@@ -362,7 +369,7 @@ static void handle_reset_button(void)
* Set the above envs to their default values, in case the user
* managed to break them.
*/
- env_set_default_vars(3, (char * const *)vars, 0);
+ env_set_default_vars(2, (char * const *)vars, 0);
/* Ensure bootcmd_rescue is used by distroboot */
env_set("boot_targets", "rescue");
--
2.31.1
[PATCH] arm64: zynqmp: Add missing year in Kria dts files
DT files have been added this year but forgot to update it that's why do it in separate patch now. Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp-sck-kv-g-revA.dts| 2 +- arch/arm/dts/zynqmp-sck-kv-g-revB.dts| 2 +- arch/arm/dts/zynqmp-sm-k26-revA-u-boot.dtsi | 2 +- arch/arm/dts/zynqmp-sm-k26-revA.dts | 2 +- arch/arm/dts/zynqmp-smk-k26-revA-u-boot.dtsi | 2 +- arch/arm/dts/zynqmp-smk-k26-revA.dts | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revA.dts b/arch/arm/dts/zynqmp-sck-kv-g-revA.dts index cca009e7c759..59d5751e0634 100644 --- a/arch/arm/dts/zynqmp-sck-kv-g-revA.dts +++ b/arch/arm/dts/zynqmp-sck-kv-g-revA.dts @@ -2,7 +2,7 @@ /* * dts file for KV260 revA Carrier Card * - * (C) Copyright 2020, Xilinx, Inc. + * (C) Copyright 2020 - 2021, Xilinx, Inc. * * SD level shifter: * "A" – A01 board un-modified (NXP) diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revB.dts b/arch/arm/dts/zynqmp-sck-kv-g-revB.dts index d004ad143954..b5443afff982 100644 --- a/arch/arm/dts/zynqmp-sck-kv-g-revB.dts +++ b/arch/arm/dts/zynqmp-sck-kv-g-revB.dts @@ -2,7 +2,7 @@ /* * dts file for KV260 revA Carrier Card * - * (C) Copyright 2020, Xilinx, Inc. + * (C) Copyright 2020 - 2021, Xilinx, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-sm-k26-revA-u-boot.dtsi b/arch/arm/dts/zynqmp-sm-k26-revA-u-boot.dtsi index 3f01233cc5a2..467df9f23a1c 100644 --- a/arch/arm/dts/zynqmp-sm-k26-revA-u-boot.dtsi +++ b/arch/arm/dts/zynqmp-sm-k26-revA-u-boot.dtsi @@ -2,7 +2,7 @@ /* * dts file for Xilinx ZynqMP K26/KV260 SD wiring * - * (C) Copyright 2020, Xilinx, Inc. + * (C) Copyright 2020 - 2021, Xilinx, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-sm-k26-revA.dts b/arch/arm/dts/zynqmp-sm-k26-revA.dts index b8a2249be426..b613ab234250 100644 --- a/arch/arm/dts/zynqmp-sm-k26-revA.dts +++ b/arch/arm/dts/zynqmp-sm-k26-revA.dts @@ -2,7 +2,7 @@ /* * dts file for Xilinx ZynqMP SM-K26 rev1/B/A * - * (C) Copyright 2020, Xilinx, Inc. + * (C) Copyright 2020 - 2021, Xilinx, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-smk-k26-revA-u-boot.dtsi b/arch/arm/dts/zynqmp-smk-k26-revA-u-boot.dtsi index 8e9106792ff9..34e6328fb66f 100644 --- a/arch/arm/dts/zynqmp-smk-k26-revA-u-boot.dtsi +++ b/arch/arm/dts/zynqmp-smk-k26-revA-u-boot.dtsi @@ -2,7 +2,7 @@ /* * dts file for Xilinx ZynqMP Z2-VSOM * - * (C) Copyright 2020, Xilinx, Inc. + * (C) Copyright 2020 - 2021, Xilinx, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-smk-k26-revA.dts b/arch/arm/dts/zynqmp-smk-k26-revA.dts index 300edc880093..c70966c1f344 100644 --- a/arch/arm/dts/zynqmp-smk-k26-revA.dts +++ b/arch/arm/dts/zynqmp-smk-k26-revA.dts @@ -2,7 +2,7 @@ /* * dts file for Xilinx ZynqMP SMK-K26 rev1/B/A * - * (C) Copyright 2020, Xilinx, Inc. + * (C) Copyright 2020 - 2021, Xilinx, Inc. * * Michal Simek */ -- 2.32.0
[PATCH] arm64: zynqmp: Add psgtr description to zc1751 dc1 board
Wire psgtr for zc1751 dc1 board.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
index f7dc0f7fb6f6..b92a2ee3e60a 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
@@ -441,4 +441,7 @@
_dpsub {
status = "okay";
+ phy-names = "dp-phy0", "dp-phy1";
+ phys = < 1 PHY_TYPE_DP 0 0>,
+ < 0 PHY_TYPE_DP 1 1>;
};
--
2.32.0
Re: [PATCH] board: sama5d3_xplained: add Falcon boot support
On 6/1/21 12:23 AM, Michael Opdenacker wrote: > This supports Falcon boot support for Microchip SAMA5D3 Xplained, > tested on raw MMC, and on raw NAND. > > spl_start_uboot() is has the simplest possible implementation. > It doesn't test the environment because enabling environment support > currently causes the SPL to exceed its maximum size (64 KiB). > It doesn't check the serial for incoming characters either because > this functionality currently doesn't seem to work from the SPL > on this board. > > Settings for Falcon boot from at FAT partition are also added to > avoid compile failures when CONFIG_SPL_OS_BOOT is enabled, but this > particular case is currently not functional as adding FAT and > partition support cause the SPL to be too big again. > > Signed-off-by: Michael Opdenacker > --- > board/atmel/sama5d3_xplained/sama5d3_xplained.c | 7 +++ > include/configs/sama5d3_xplained.h | 14 ++ > 2 files changed, 21 insertions(+) > Applied to u-boot-atmel/next , thanks !
Re: [PATCH] configs: sam boards: add hash command
On 5/26/21 4:19 PM, Eugen Hristev wrote: > Add hash and hash verify commands. These would be useful for > verifying copied data. > > Signed-off-by: Eugen Hristev > --- > configs/sam9x60ek_mmc_defconfig| 2 ++ > configs/sam9x60ek_nandflash_defconfig | 2 ++ > configs/sam9x60ek_qspiflash_defconfig | 2 ++ > configs/sama5d27_som1_ek_mmc1_defconfig| 2 ++ > configs/sama5d27_som1_ek_mmc_defconfig | 2 ++ > configs/sama5d27_som1_ek_qspiflash_defconfig | 2 ++ > configs/sama5d27_wlsom1_ek_mmc_defconfig | 2 ++ > configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 2 ++ > configs/sama5d2_icp_mmc_defconfig | 2 ++ > configs/sama5d2_ptc_ek_mmc_defconfig | 2 ++ > configs/sama5d2_ptc_ek_nandflash_defconfig | 2 ++ > configs/sama5d2_xplained_emmc_defconfig| 2 ++ > configs/sama5d2_xplained_mmc_defconfig | 2 ++ > configs/sama5d2_xplained_qspiflash_defconfig | 2 ++ > configs/sama5d2_xplained_spiflash_defconfig| 2 ++ > configs/sama5d3_xplained_mmc_defconfig | 2 ++ > configs/sama5d3_xplained_nandflash_defconfig | 2 ++ > configs/sama5d4_xplained_mmc_defconfig | 2 ++ > configs/sama5d4_xplained_nandflash_defconfig | 2 ++ > configs/sama5d4_xplained_spiflash_defconfig| 2 ++ > configs/sama7g5ek_mmc1_defconfig | 2 ++ > configs/sama7g5ek_mmc_defconfig| 2 ++ > 22 files changed, 44 insertions(+) > Applied to u-boot-atmel/next
[PATCH] arm: snapdragon: Use correct GICC register on APQ8016
The GICC register used by u-boot is 0x0a20c000, which is actually a GICC for WCNSS, the WLAN processor. U-boot runs on the Application Processor, therefore it should use APCS GICC instead. Hence, correct it with APCS GICC register address. Signed-off-by: Sheep Sun --- arch/arm/mach-snapdragon/include/mach/sysmap-apq8016.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-snapdragon/include/mach/sysmap-apq8016.h b/arch/arm/mach-snapdragon/include/mach/sysmap-apq8016.h index 520e2e6bd7..d9a3b1af98 100644 --- a/arch/arm/mach-snapdragon/include/mach/sysmap-apq8016.h +++ b/arch/arm/mach-snapdragon/include/mach/sysmap-apq8016.h @@ -8,7 +8,7 @@ #define _MACH_SYSMAP_APQ8016_H #define GICD_BASE (0x0b00) -#define GICC_BASE (0x0a20c000) +#define GICC_BASE (0x0b002000) /* Clocks: (from CLK_CTL_BASE) */ #define GPLL0_STATUS (0x2101C) -- 2.30.2
Re: [PATCH] smbios: Fix calculating BIOS Release Date
On Friday 23 April 2021 11:14:44 Pali Rohár wrote: > On Friday 23 April 2021 11:04:26 Mark Kettenis wrote: > > > Date: Fri, 23 Apr 2021 10:27:16 +0200 > > > From: Pali Rohár > > > > > > On Friday 23 April 2021 10:25:21 Bin Meng wrote: > > > > Hi Pali, > > > > > > > > On Fri, Apr 23, 2021 at 12:10 AM Pali Rohár wrote: > > > > > > > > > > BIOS Release Date must be in format mm/dd/ and must be release > > > > > date. > > > > > U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro > > > > > which is > > > > > generated from current build timestamp. > > > > > > > > > > Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version > > > > > which is > > > > > better approximation of U-Boot release date than current build > > > > > timestamp. > > > > > Current U-Boot versioning is in format .mm so as a day choose 01. > > > > > > > > > > Some operating systems are using BIOS Release Date for detecting when > > > > > was > > > > > SMBIOS table filled or if it could support some feature (e.g. BIOS > > > > > from > > > > > 1990 cannot support features invented in 2000). So this change also > > > > > ensures > > > > > that recompiling U-Boot from same sources but in different year does > > > > > not > > > > > change behavior of some operating systems. > > > > > > > > > > Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c > > > > > so remove it from global autogenerated files and also from Makefile. > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > --- > > > > > Makefile| 2 -- > > > > > doc/develop/version.rst | 1 - > > > > > lib/smbios.c| 23 +++ > > > > > 3 files changed, 23 insertions(+), 3 deletions(-) > > > > > > > > > > > > > With this change the U-Boot date is only the release date, so one > > > > cannot tell exact BIOS date on which U-Boot was built from. > > > > > > Hello Bin! I understood that this is expected and it should be the > > > release date, not the build date. But maybe it has different meanings in > > > different contexts? > > > > To be honest, I think the BIOS data as advertised by SMBIOS is fairly > > useless for an open source firmware solution like U-Boot. With > > multiple branches and forks in existence a single date doesn't really > > give you a good clue about what bugs might be present in the firmware > > or whether you are running the most up-to-date version. > > > > Note that we already advertise the U-Boot release in the EFI firmware > > revision: > > > > efi0 at mainbus0: UEFI 2.8 > > efi0: Das U-Boot rev 0x20200700 > > > > so doing the same for SMBIOS doesn't really provide more information. > > Using the build date at least tells you how old the firmware is you're > > using... > > > > I'm pretty sure traditional closed source firmware on x86 uses the > > build date here as well. > > There is a difference, that this closed source firmware in most cases > cannot be recompiled therefore its "BIOS Release Date" is not changed > after "releasing" binary blob. So one version of this closed firmware > has only one BIOS Release Date. > > But because U-Boot is distributed in source code and "BIOS Release Date" > is filled at compile time, it can be any value and therefore one U-Boot > version may have different values in "BIOS Release Date" section. > > So... would not it be better to advertise stable (predictable) U-Boot > version as "BIOS Release Date" and "UEFI revision" instead of > unpredictable compilation timestamp? I have looked and basically BIOS Release Date is used by operating systems as a check that some bugs or functionality may be present. So it really should be treated as "version" and not as "compile time" in U-Boot. And I think same applies also for UEFI revision.
Re: [PATCH V2] MAINTAINER, git-mailrc: Update the mmc maintainer
On Mon, Jun 14, 2021 at 1:45 PM Jaehoon Chung wrote: > > Update to me as co-maintainer with Peng. > Additionally, fix the alias in git-mailrc. nits: technically it's not "fix" but "update" the mmc alias > > Signed-off-by: Jaehoon Chung > --- > Changelog on V2 > - Keep original alias > --- > MAINTAINERS| 1 + > doc/git-mailrc | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > Otherwise, Reviewed-by: Bin Meng
[PATCH -next] ARM: dts: k3-j7200-common-proc-board-u-boot.dtsi: Fix dtc warnings
Fix following dtc warning by explicitly setting up #size-cells
and #address-cells when overriding node in -u-boot.dtsi
arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (reg_format):
/bus@10/bus@2838/mcu-navss/ringacc@2b80:reg: property has
invalid length (80 bytes) (#address-cells == 2, #size-cells == 1)
Signed-off-by: Vignesh Raghavendra
---
arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index 41ce9fcb59..786cc48050 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -43,6 +43,8 @@
mcu-navss{
u-boot,dm-spl;
+ #address-cells = <2>;
+ #size-cells = <2>;
ringacc@2b80 {
reg = <0x0 0x2b80 0x0 0x40>,
--
2.32.0
Re: [GIT PULL v2] TI changes for v2021.10 next
On 6/14/21 1:35 PM, Tero Kristo wrote: > On 13/06/2021 19:49, Tom Rini wrote: >> On Fri, Jun 11, 2021 at 09:40:14PM +0530, Lokesh Vutla wrote: >> >>> Hi Tom, >>> Please find the PR for master branch targeted for v2021.10-next >>> branch >>> with checkpatch warnings fixed. Details about the PR are updated in >>> the tag message. >>> >>> Gitlab CI report: >>> https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7817 >>> >>> The following changes since commit >>> e8f720ee1707b43a0e14ade87b40a1f84baeb2f3: >>> >>> Merge branch '2021-06-08-kconfig-migrations' into next (2021-06-09 >>> 08:19:13 -0400) >>> >>> are available in the Git repository at: >>> >>> https://source.denx.de/u-boot/custodians/u-boot-ti.git >>> tags/ti-v2021.10-next-v2 >>> >>> for you to fetch changes up to 5abb694d6016eaf497c3d9a3ec79382e217e7508: >>> >>> dma: ti: k3-udma: Add support for native configuration of >>> chan/flow (2021-06-11 19:18:52 +0530) >>> >> >> I've applied this to u-boot/next now. But please follow up to fix: >> w+(j7200_evm_a72 j721e_evm_a72 j721e_hs_evm_a72 j7200_evm_r5 >> j721e_evm_r5 j721e_hs_evm_r5) >> arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (reg_format): >> /bus@10/bus@2838/mcu-navss/ringacc@2b80:reg: property has >> invalid length (80 bytes) (#address-cells == 2, #size-cells == 1) >> >> and all of the other dtc warnings. Thanks! >> > > Thanks a lot Tom! > > I think those DTC warnings are coming out of the DMA support series from > Vignesh. Vignesh, any comments? > I had provided a diff to squash at [1]. Looks like that was not picked up. Will send a follow up patch. [1] https://lore.kernel.org/u-boot/c8a8bad1-cd13-344e-5701-02748bb00...@ti.com/
Re: [GIT PULL v2] TI changes for v2021.10 next
On 13/06/2021 19:49, Tom Rini wrote: On Fri, Jun 11, 2021 at 09:40:14PM +0530, Lokesh Vutla wrote: Hi Tom, Please find the PR for master branch targeted for v2021.10-next branch with checkpatch warnings fixed. Details about the PR are updated in the tag message. Gitlab CI report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7817 The following changes since commit e8f720ee1707b43a0e14ade87b40a1f84baeb2f3: Merge branch '2021-06-08-kconfig-migrations' into next (2021-06-09 08:19:13 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.10-next-v2 for you to fetch changes up to 5abb694d6016eaf497c3d9a3ec79382e217e7508: dma: ti: k3-udma: Add support for native configuration of chan/flow (2021-06-11 19:18:52 +0530) I've applied this to u-boot/next now. But please follow up to fix: w+(j7200_evm_a72 j721e_evm_a72 j721e_hs_evm_a72 j7200_evm_r5 j721e_evm_r5 j721e_hs_evm_r5) arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (reg_format): /bus@10/bus@2838/mcu-navss/ringacc@2b80:reg: property has invalid length (80 bytes) (#address-cells == 2, #size-cells == 1) and all of the other dtc warnings. Thanks! Thanks a lot Tom! I think those DTC warnings are coming out of the DMA support series from Vignesh. Vignesh, any comments? -Tero
Re: [PATCH] arm64: zynqmp: Add support for 64bit addresses in its
po 7. 6. 2021 v 12:55 odesílatel Michal Simek napsal:
>
> Xilinx ZynqMP supports also addresses above 4GB (32bit) that's why also
> generate u-boot.its with 64bit load/entry addresses to also support
> different configurations.
>
> Signed-off-by: Michal Simek
> ---
>
> arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> index 700871dbe109..592be7f67066 100755
> --- a/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> +++ b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> @@ -13,6 +13,8 @@ BL31_ELF="${BL31%.*}.elf"
> awk '/Entry point/ { print $3 }'`
>
> [ -z "$ATF_LOAD_ADDR" ] && ATF_LOAD_ADDR="0xfffea000"
> +ATF_LOAD_ADDR_LOW=`printf 0x%x $((ATF_LOAD_ADDR & 0x))`
> +ATF_LOAD_ADDR_HIGH=`printf 0x%x $((ATF_LOAD_ADDR >> 32))`
>
> [ -z "$BL32" ] && BL32="tee.bin"
> BL32_ELF="${BL32%.*}.elf"
> @@ -20,14 +22,20 @@ BL32_ELF="${BL32%.*}.elf"
> awk '/Entry point/ { print $3 }'`
>
> [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0x6000"
> +TEE_LOAD_ADDR_LOW=`printf 0x%x $((TEE_LOAD_ADDR & 0x))`
> +TEE_LOAD_ADDR_HIGH=`printf 0x%x $((TEE_LOAD_ADDR >> 32))`
>
> if [ -z "$BL33_LOAD_ADDR" ];then
> BL33_LOAD_ADDR=`awk '/CONFIG_SYS_TEXT_BASE/ { print $3 }'
> include/generated/autoconf.h`
> fi
> +BL33_LOAD_ADDR_LOW=`printf 0x%x $((BL33_LOAD_ADDR & 0x))`
> +BL33_LOAD_ADDR_HIGH=`printf 0x%x $((BL33_LOAD_ADDR >> 32))`
>
> DTB_LOAD_ADDR=`awk '/CONFIG_XILINX_OF_BOARD_DTB_ADDR/ { print $3 }'
> include/generated/autoconf.h`
> if [ ! -z "$DTB_LOAD_ADDR" ]; then
> - DTB_LOAD="load = <$DTB_LOAD_ADDR>;"
> + DTB_LOAD_ADDR_LOW=`printf 0x%x $((DTB_LOAD_ADDR & 0x))`
> + DTB_LOAD_ADDR_HIGH=`printf 0x%x $((DTB_LOAD_ADDR >> 32))`
> + DTB_LOAD="load = <$DTB_LOAD_ADDR_HIGH $DTB_LOAD_ADDR_LOW>;"
> else
> DTB_LOAD=""
> fi
> @@ -59,8 +67,8 @@ cat << __HEADER_EOF
> os = "u-boot";
> arch = "arm64";
> compression = "none";
> - load = <$BL33_LOAD_ADDR>;
> - entry = <$BL33_LOAD_ADDR>;
> + load = <$BL33_LOAD_ADDR_HIGH $BL33_LOAD_ADDR_LOW>;
> + entry = <$BL33_LOAD_ADDR_HIGH $BL33_LOAD_ADDR_LOW>;
> hash {
> algo = "md5";
> };
> @@ -76,8 +84,8 @@ cat << __ATF
> os = "arm-trusted-firmware";
> arch = "arm64";
> compression = "none";
> - load = <$ATF_LOAD_ADDR>;
> - entry = <$ATF_LOAD_ADDR>;
> + load = <$ATF_LOAD_ADDR_HIGH $ATF_LOAD_ADDR_LOW>;
> + entry = <$ATF_LOAD_ADDR_HIGH $ATF_LOAD_ADDR_LOW>;
> hash {
> algo = "md5";
> };
> @@ -94,8 +102,8 @@ cat << __TEE
> os = "tee";
> arch = "arm64";
> compression = "none";
> - load = <$TEE_LOAD_ADDR>;
> - entry = <$TEE_LOAD_ADDR>;
> + load = <$TEE_LOAD_ADDR_HIGH $TEE_LOAD_ADDR_LOW>;
> + entry = <$TEE_LOAD_ADDR_HIGH $TEE_LOAD_ADDR_LOW>;
> hash {
> algo = "md5";
> };
> --
> 2.31.1
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 0/6] arm64: zynqmp: DT syncup patches
čt 3. 6. 2021 v 10:11 odesílatel Michal Simek napsal: > > Hi, > > this series is trying to clean and sync DTS files. At the end we want to > have all these files be in sync with the Linux kernel based on DT binding > available in the Linux kernel. > > Thanks, > Michal > > > Michal Simek (6): > arm64: zynqmp: Remove additional header from zc1232 DT > arm64: zynqmp: Add maximum-speed property for dwc3 nodes > arm64: zynqmp: Remove addition newline from zc1751 dc1 > arm64: zynqmp: Remove unused dp_aclk clock > arm64: zynqmp: Sync dp port location on zc1751 dc4 > arm64: zynqmp: Sync psgtr location on zcu100/zcu106 > > arch/arm/dts/zynqmp-clk-ccf.dtsi | 7 --- > arch/arm/dts/zynqmp-zc1232-revA.dts | 1 - > arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 2 +- > arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 16 > arch/arm/dts/zynqmp-zcu100-revC.dts | 14 +++--- > arch/arm/dts/zynqmp-zcu106-revA.dts | 15 --- > arch/arm/dts/zynqmp-zcu111-revA.dts | 1 + > arch/arm/dts/zynqmp-zcu208-revA.dts | 1 + > arch/arm/dts/zynqmp-zcu216-revA.dts | 1 + > 9 files changed, 27 insertions(+), 31 deletions(-) > > -- > 2.31.1 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH] arm64: zynqmp: Remove gpio from aliases list
It is not recommended to have aliases for gpio. In past it was used in Linux for assigning numbers via sysfs which is deprecated and libgpiod should be used instead. In U-Boot this number is used for seq number but gpio offset are not counted from this number. That's why having these aliases only for seq number is not needed. As is done in Linux it is the best to use full gpio name instead of sequence number which depends on sequence in binding. Signed-off-by: Michal Simek --- ZynqMP> gpio status -a Bank gpio@ff0a: gpio@ff0a0: input: 0 [ ] gpio@ff0a1: input: 0 [ ] gpio@ff0a2: input: 0 [ ] gpio@ff0a3: input: 0 [ ] gpio@ff0a4: input: 0 [ ] gpio@ff0a5: input: 0 [ ] gpio@ff0a6: input: 0 [ ] gpio@ff0a7: input: 0 [ ] gpio@ff0a8: input: 0 [ ] gpio@ff0a9: input: 0 [ ] gpio@ff0a10: input: 0 [ ] gpio@ff0a11: input: 0 [ ] gpio@ff0a12: input: 0 [ ] gpio@ff0a13: input: 1 [ ] gpio@ff0a14: input: 0 [ ] gpio@ff0a15: input: 0 [ ] gpio@ff0a16: input: 0 [ ] gpio@ff0a17: input: 0 [ ] gpio@ff0a18: input: 0 [ ] gpio@ff0a19: input: 0 [ ] gpio@ff0a20: input: 0 [ ] gpio@ff0a21: input: 0 [ ] gpio@ff0a22: input: 0 [ ] gpio@ff0a23: input: 1 [ ] gpio@ff0a24: input: 0 [ ] gpio@ff0a25: input: 0 [ ] gpio@ff0a26: input: 1 [ ] gpio@ff0a27: input: 0 [ ] gpio@ff0a28: input: 0 [ ] gpio@ff0a29: input: 0 [ ] gpio@ff0a30: input: 0 [ ] gpio@ff0a31: output: 1 [ ] gpio@ff0a32: input: 0 [ ] gpio@ff0a33: input: 0 [ ] gpio@ff0a34: input: 0 [ ] gpio@ff0a35: input: 0 [ ] gpio@ff0a36: input: 0 [ ] gpio@ff0a37: input: 0 [ ] gpio@ff0a38: input: 0 [ ] gpio@ff0a39: input: 0 [ ] gpio@ff0a40: input: 0 [ ] gpio@ff0a41: input: 0 [ ] gpio@ff0a42: input: 0 [ ] gpio@ff0a43: input: 0 [ ] gpio@ff0a44: input: 0 [ ] gpio@ff0a45: input: 0 [ ] gpio@ff0a46: input: 0 [ ] gpio@ff0a47: input: 0 [ ] gpio@ff0a48: input: 0 [ ] gpio@ff0a49: input: 0 [ ] gpio@ff0a50: input: 0 [ ] gpio@ff0a51: input: 0 [ ] gpio@ff0a52: input: 0 [ ] gpio@ff0a53: input: 0 [ ] gpio@ff0a54: input: 0 [ ] gpio@ff0a55: input: 0 [ ] gpio@ff0a56: input: 0 [ ] gpio@ff0a57: input: 0 [ ] gpio@ff0a58: input: 0 [ ] gpio@ff0a59: input: 0 [ ] gpio@ff0a60: input: 0 [ ] gpio@ff0a61: input: 0 [ ] gpio@ff0a62: input: 0 [ ] gpio@ff0a63: input: 0 [ ] gpio@ff0a64: input: 0 [ ] gpio@ff0a65: input: 0 [ ] gpio@ff0a66: input: 0 [ ] gpio@ff0a67: input: 0 [ ] gpio@ff0a68: input: 0 [ ] gpio@ff0a69: input: 0 [ ] gpio@ff0a70: input: 0 [ ] gpio@ff0a71: input: 0 [ ] gpio@ff0a72: input: 0 [ ] gpio@ff0a73: input: 0 [ ] gpio@ff0a74: input: 0 [ ] gpio@ff0a75: input: 0 [ ] gpio@ff0a76: input: 0 [ ] gpio@ff0a77: input: 0 [ ] gpio@ff0a78: input: 0 [ ] gpio@ff0a79: input: 0 [ ] gpio@ff0a80: input: 0 [ ] gpio@ff0a81: input: 0 [ ] gpio@ff0a82: input: 0 [ ] gpio@ff0a83: input: 0 [ ] gpio@ff0a84: input: 0 [ ] gpio@ff0a85: input: 0 [ ] gpio@ff0a86: input: 0 [ ] gpio@ff0a87: input: 0 [ ] gpio@ff0a88: input: 0 [ ] gpio@ff0a89: input: 0 [ ] gpio@ff0a90: input: 0 [ ] gpio@ff0a91: input: 0 [ ] gpio@ff0a92: input: 0 [ ] gpio@ff0a93: input: 0 [ ] gpio@ff0a94: input: 0 [ ] gpio@ff0a95: input: 0 [ ] gpio@ff0a96: input: 0 [ ] gpio@ff0a97: input: 0 [ ] gpio@ff0a98: input: 0 [ ] gpio@ff0a99: input: 0 [ ] gpio@ff0a100: input: 0 [ ] gpio@ff0a101: input: 0 [ ] gpio@ff0a102: input: 0 [ ] gpio@ff0a103: input: 0 [ ] gpio@ff0a104: input: 0 [ ] gpio@ff0a105: input: 0 [ ] gpio@ff0a106: input: 0 [ ] gpio@ff0a107: input: 0 [ ] gpio@ff0a108: input: 0 [ ] gpio@ff0a109: input: 0 [ ] gpio@ff0a110: input: 0 [ ] gpio@ff0a111: input: 0 [ ] gpio@ff0a112: input: 0 [ ] gpio@ff0a113: input: 0 [ ] gpio@ff0a114: input: 0 [ ] gpio@ff0a115: input: 0 [ ] gpio@ff0a116: input: 0 [ ] gpio@ff0a117: input: 0 [ ] gpio@ff0a118: input: 0 [ ] gpio@ff0a119: input: 0 [ ] gpio@ff0a120: input: 0 [ ] gpio@ff0a121: input: 0 [ ] gpio@ff0a122: input: 0 [ ] gpio@ff0a123: input: 0 [ ] gpio@ff0a124: input: 0 [ ] gpio@ff0a125: input: 0 [ ] gpio@ff0a126: input: 0 [ ] gpio@ff0a127: input: 0 [ ] gpio@ff0a128: input: 0 [ ] gpio@ff0a129: input: 0 [ ] gpio@ff0a130: input: 0 [ ] gpio@ff0a131: input: 0 [ ] gpio@ff0a132: input: 0 [ ] gpio@ff0a133: input: 0 [ ] gpio@ff0a134: input: 0 [ ] gpio@ff0a135: input: 0 [ ] gpio@ff0a136: input: 0 [ ] gpio@ff0a137: input: 0 [ ] gpio@ff0a138: input: 0 [ ] gpio@ff0a139: input: 0 [ ] gpio@ff0a140: input: 0 [ ] gpio@ff0a141: input: 0 [ ] gpio@ff0a142: input: 0 [ ] gpio@ff0a143: input: 0 [ ] gpio@ff0a144: input: 0 [ ] gpio@ff0a145: input: 0 [ ] gpio@ff0a146: input: 0 [ ] gpio@ff0a147:
Re: [PATCH 0/7] arm64: zynqmp: DT syncup patches next
po 7. 6. 2021 v 12:15 odesílatel Michal Simek napsal: > > Hi, > > this is the next series which is trying to clean and sync DTS files. > At the end we want to have all these files be in sync with the Linux kernel > based on DT binding available in the Linux kernel. > > Thanks, > Michal > > > Michal Simek (6): > xilinx: Convert xlnx,eeprom property to nvmem alias > arm64: zynqmp: Remove si5328 and si5382 nodes > arm64: zynqmp: Remove can aliases from zc1751 > arm64: zynqmp: Remove unused property from SD/USB > arm64: zynqmp: Remove information about dma clock on zcu106 > arm64: zynqmp: Sync psgtr location on zcu104/zcu111/zc1751-dc1 > > Srinivas Neeli (1): > arm64: zynqmp: rtc: Update rtc calibration value > > ...ultrazedev-cc-v1.0-ultrazedev-som-v1.0.dts | 2 +- > arch/arm/dts/zynq-syzygy-hub.dts | 2 +- > arch/arm/dts/zynqmp-a2197-revA.dts| 3 ++- > arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 2 +- > arch/arm/dts/zynqmp-g-a2197-00-revA.dts | 2 +- > arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 2 +- > arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 2 +- > arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 2 +- > arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 3 +-- > arch/arm/dts/zynqmp-sm-k26-revA.dts | 4 ++-- > arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 14 +-- > arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 2 -- > arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 2 -- > arch/arm/dts/zynqmp-zcu102-revA.dts | 12 ++ > arch/arm/dts/zynqmp-zcu104-revA.dts | 20 > arch/arm/dts/zynqmp-zcu104-revC.dts | 21 - > arch/arm/dts/zynqmp-zcu106-revA.dts | 23 ++- > arch/arm/dts/zynqmp-zcu111-revA.dts | 21 - > arch/arm/dts/zynqmp-zcu208-revA.dts | 2 +- > arch/arm/dts/zynqmp-zcu216-revA.dts | 2 +- > arch/arm/dts/zynqmp.dtsi | 10 +--- > 21 files changed, 53 insertions(+), 100 deletions(-) > > -- > 2.31.1 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCHv2] zynqmp: spl: support DRAM ECC initialization
On 6/13/21 8:55 PM, Jorge Ramirez-Ortiz wrote: > Use the ZDMA channel 0 to initialize the DRAM banks. This avoid > spurious ECC errors that can occur when accessing unitialized memory. > > The feature is enabled by setting the option > CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT and providing the following data: > > SPL_ZYNQMP_DRAM_BANK1_BASE: start of memory to initialize > SPL_ZYNQMP_DRAM_BANK1_LEN : len of memory to initialize (hex) > SPL_ZYNQMP_DRAM_BANK2_BASE: start of memory to initialize > SPL_ZYNQMP_DRAM_BANK2_LEN : len of memory to initialize (hex) > > Setting SPL_ZYNQMP_DRAM_BANK_LEN to 0 takes no action. > > Signed-off-by: Jorge Ramirez-Ortiz > --- > v2: extend commit message > _BASE suffix for DRAM_BANK address > DRAM_BANK2_BASE to 0x8.00.00.00.00 > remove unnecessary includes from ecc_spl_init.c > add ADMA_CH0_BASEADDR to hardware.h > remove cache management > timeout on loops > retry once on DMA status error > move DMA restore to reset values to its own function(*) > removed extern clause from splc and added header file instead > fixed duplicated call to board_early_init_r() > > (*) IP reset: there is no register to toggle (checked docs and linux > kernel) >opted for leaving the restore function as per FSBL > > > arch/arm/mach-zynqmp/Kconfig | 35 > arch/arm/mach-zynqmp/Makefile | 1 + > arch/arm/mach-zynqmp/ecc_spl_init.c | 163 ++ > .../mach-zynqmp/include/mach/ecc_spl_init.h | 13 ++ > arch/arm/mach-zynqmp/include/mach/hardware.h | 2 + > arch/arm/mach-zynqmp/spl.c| 4 + > 6 files changed, 218 insertions(+) > create mode 100644 arch/arm/mach-zynqmp/ecc_spl_init.c > create mode 100644 arch/arm/mach-zynqmp/include/mach/ecc_spl_init.h > > diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig > index f1301f6661..39144d654e 100644 > --- a/arch/arm/mach-zynqmp/Kconfig > +++ b/arch/arm/mach-zynqmp/Kconfig > @@ -92,6 +92,41 @@ config ZYNQMP_NO_DDR > This option configures MMU with no DDR to avoid speculative > access to DDR memory where DDR is not present. > > +config SPL_ZYNQMP_DRAM_ECC_INIT > + bool "Initialize DRAM ECC" > + depends on SPL > + help > + This option initializes all memory to 0xdeadbeef. Must be set if your > + memory is of ECC type. > + > +config SPL_ZYNQMP_DRAM_BANK1_BASE > + depends on SPL_ZYNQMP_DRAM_ECC_INIT > + hex "DRAM Bank1 address" > + default 0x > + help > + Start address of DRAM ECC bank1 > + > +config SPL_ZYNQMP_DRAM_BANK1_LEN > + depends on SPL_ZYNQMP_DRAM_ECC_INIT > + hex "DRAM Bank1 size" > + default 0x8000 > + help > + Size in bytes of the DRAM ECC bank1 > + > +config SPL_ZYNQMP_DRAM_BANK2_BASE > + depends on SPL_ZYNQMP_DRAM_ECC_INIT > + hex "DRAM Bank2 address" > + default 0x8 > + help > + Start address of DRAM ECC bank2 > + > +config SPL_ZYNQMP_DRAM_BANK2_LEN > + depends on SPL_ZYNQMP_DRAM_ECC_INIT > + hex "DRAM Bank2 size" > + default 0x0 > + help > + Size in bytes of the DRAM ECC bank2. A null size takes no action. > + > config SYS_MALLOC_F_LEN > default 0x600 > > diff --git a/arch/arm/mach-zynqmp/Makefile b/arch/arm/mach-zynqmp/Makefile > index 8a3b074724..eb6c5112b3 100644 > --- a/arch/arm/mach-zynqmp/Makefile > +++ b/arch/arm/mach-zynqmp/Makefile > @@ -7,4 +7,5 @@ obj-y += clk.o > obj-y+= cpu.o > obj-$(CONFIG_MP) += mp.o > obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o > +obj-$(CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT) += ecc_spl_init.o > obj-$(CONFIG_ZYNQMP_PSU_INIT_ENABLED)+= psu_spl_init.o > diff --git a/arch/arm/mach-zynqmp/ecc_spl_init.c > b/arch/arm/mach-zynqmp/ecc_spl_init.c > new file mode 100644 > index 00..f547d8e3a5 > --- /dev/null > +++ b/arch/arm/mach-zynqmp/ecc_spl_init.c > @@ -0,0 +1,163 @@ > +// SPDX-License-Identifier: MIT > +/* > + * Copyright(c) 2015 - 2020 Xilinx, Inc. > + * > + * Jorge Ramirez-Ortiz > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define ZDMA_TRANSFER_MAX_LEN(0x3FFFU - 7U) > +#define ZDMA_CH_STATUS ((ADMA_CH0_BASEADDR) + > 0x011CU) > +#define ZDMA_CH_STATUS_STATE_MASK0x0003U > +#define ZDMA_CH_STATUS_STATE_DONE0xU > +#define ZDMA_CH_STATUS_STATE_ERR 0x0003U > +#define ZDMA_CH_CTRL0((ADMA_CH0_BASEADDR) + > 0x0110U) > +#define ZDMA_CH_CTRL0_POINT_TYPE_MASK(u32)0x0040U > +#define ZDMA_CH_CTRL0_POINT_TYPE_NORMAL (u32)0xU > +#define ZDMA_CH_CTRL0_MODE_MASK (u32)0x0030U > +#define ZDMA_CH_CTRL0_MODE_WR_ONLY (u32)0x0010U > +#define ZDMA_CH_CTRL0_TOTAL_BYTE_COUNT ((ADMA_CH0_BASEADDR) + > 0x0188U) > +#define
